[slscripters] llHTTPRequest("https://...") + SNI = status 499?

[Jessica Stein]

I have been trying to connect to my server securely using SSL but it always results in status 499.

It occurred to me that llHTTPRequest() may not support SNI http://en.wikipedia.org/wiki/Server_Name_Indication

In which case it may be receiving a certificate for the wrong domain and rejecting it because of the domain mismatch despite setting HTTP_VERIFY_CERT to FALSE.

The questions are:
Does llHTTPRequest() support SNI?
If not, can it?
Does HTTP_VERIFY_CERT only disable verifying the Certificate Authority?
If so, should it also disable domain checks, expiry or should there be another setting to disable that?
Can the 499 status be divided into different numbers to clarify what the failure was or there be a way of getting more error information? (maybe in the body)

Can the documentation be clarified to address whatever the situation may be?

Here is a piece of failing code:

string URL = "https://buysensations.com/name2key.php";
string avname = "Amethyst Rosencrans";
key requestkey;

default
{
    state_entry()
    {
        requestkey = llHTTPRequest(URL,[HTTP_VERIFY_CERT,FALSE,HTTP_METHOD,"POST"],"s=people&q=" + llEscapeURL(avname));
    }

    http_response(key request_id, integer status, list metadata, string body)
    {
        if(requestkey == request_id)
        {
            llOwnerSay("Status " + (string)status + " Body: " + body);
        }
    }
}

Thanks,

Jessica
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

[Darien Caldwell]

I suspect Kelly Linden would be the one to know the answer to this.

 

Calling Kelly, where are you? :)

[Darien Caldwell]

You may want to try getting Kelly at his office hours:  https://wiki.secondlife.com/wiki/Linden_Lab_Official:User_Groups

Monday's 9AM-10AM at http://maps.secondlife.com/secondlife/Ambleside/157/91/30

 

                  - Dari

[Kelly Linden]

HTTP_VERIFY_CERT flag controls the CURLOPT_SSL_VERIFYPEER option given to curl for the request:

CURLOPT_SSL_VERIFYPEER

This option determines whether curl verifies the authenticity of the peer's certificate. A value of 1 means curl verifies; 0 (zero) means it doesn't.

When negotiating a SSL connection, the server sends a certificate indicating its identity. Curl verifies whether the certificate is authentic, i.e. that you can trust that the server is who the certificate says it is. This trust is based on a chain of digital signatures, rooted in certification authority (CA) certificates you supply. curl uses a default bundle of CA certificates (the path for that is determined at build time) and you can specify alternate certificates with the CURLOPT_CAINFO option or the CURLOPT_CAPATH option.

When CURLOPT_SSL_VERIFYPEER is nonzero, and the verification fails to prove that the certificate is authentic, the connection fails. When the option is zero, the peer certificate verification succeeds regardless.

Authenticating the certificate is not by itself very useful. You typically want to ensure that the server, as authentically identified by its certificate, is the server you mean to be talking to. Use CURLOPT_SSL_VERIFYHOST to control that. The check that the host name in the certificate is valid for the host name you're connecting to is done independently of the CURLOPT_SSL_VERIFYPEER option.

Of note it does not modify the CURLOPT_SSL_VERIFYHOST option:

CURLOPT_SSL_VERIFYHOST

This option determines whether libcurl verifies that the server cert is for the server it is known as.

When negotiating a SSL connection, the server sends a certificate indicating its identity.

When CURLOPT_SSL_VERIFYHOST is 2, that certificate must indicate that the server is the server to which you meant to connect, or the connection fails.

Curl considers the server the intended one when the Common Name field or a Subject Alternate Name field in the certificate matches the host name in the URL to which you told Curl to connect.

When the value is 1, the certificate must contain a Common Name field, but it doesn't matter what name it says. (This is not ordinarily a useful setting).

When the value is 0, the connection succeeds regardless of the names in the certificate.

The default value for this option is 2.

Hope this helps. The above was from: http://curl.haxx.se/libcurl/c/curl_easy_setopt.html

 - Kelly

[Darien Caldwell]

So if I interpret that correctly, HTTP_VERIFY_CERT simply gives unauthenticated certificates a pass. But the CURLOPT_SSL_VERIFYHOST being set to 2 still requires that the certificate must point to the originating server.  In short, SNI scenarios won't work.  Thanks Kelly.

 

                   - Dari

[Montavious Peccable]

The way I read it, with HTTP_VERIFY_CERT set and CURLOPT_SSL_VERIFYHOST not set, the cert must be valid but need not be for the "right" host. That's a little looser than SNI as I understand it, but should enable your cert to work. Or did I miss something?

Rick

[Darien Caldwell]

Montavious, I think your interpretation is correct. However, I get the impression that LL has the CURLOPT_SLL_VERIFYHOST set to it's default, which is 2.  Kelly didn't actually state this, but his pointing out that HTTP_VERIFY_CERT doesnt' modify it would indicate that.

 

            - Dari

[Jessica Stein]

Kelly,

What version of curl do the simulators have?  According to wikipedia this version of curl supports SNI:

libcurl / cURL since 7.18.1 (released 30 Mar 2008) when compiled against an SSL/TLS toolkit with SNI support

If the curl supports SNI it should get a certificate for the correct domain.

Jessica

---

From: Kelly Linden <ke...@lindenlab.com>
To: Darien Caldwell <darien....@logos-cards.com>
Cc: "secondlif...@lists.secondlife.com" <secondlif...@lists.secondlife.com>
Sent: Monday, February 27, 2012 10:34 AM
Subject: Re: [slscripters] llHTTPRequest("https://...") + SNI = status 499?

HTTP_VERIFY_CERT flag controls the CURLOPT_SSL_VERIFYPEER option given to curl for the request:

[Kelly Linden]

We use a later version than that.

 - Kelly

[Jessica Stein]

What about the SSL/TLS stuff does it support SNI? can we tell what error is causing the 499? I am just speculating that it is the lack of SNI support that is causing the failure.

Jessica

---

From: Kelly Linden <ke...@lindenlab.com>

To: Jessica Stein <sunset...@yahoo.com>
Cc: Darien Caldwell <darien....@logos-cards.com>; "secondlif...@lists.secondlife.com" <secondlif...@lists.secondlife.com>
Sent: Wednesday, February 29, 2012 11:36 PM

Subject: Re: [slscripters] llHTTPRequest("https://...") + SNI = status 499?