I testet the "Download()" function in CkHTTP to get content from a webserver with TLS SNI (RFC3546) enabled. But no hostname was send to it.
With SNI the client send the hostname as part of the Client Hello in TLS. This is supported by every major webbrowser. The advantage for the server side is, that more than one HTTPS-website can be hosted with one IP and on the same port.
Is there a possibility to enable it or is it planned as new feature?
This is implemented for the next version (v220.127.116.11). If you would like to test a pre-release, please indicate the exact build required (operating system, programming language, architecture, etc.)
That is great. I'm happy to test it with a pre-release. We use the Microsoft Visual Studio C++ 2010 SP1 32 Bit (Windows) Build.
Here is a new pre-release build you can test:
I have tested the pre-release build. It is working if no http proxy is configured. Then the SNI extension is send. If a http proxy is set, the extension is missing in the Client Hello message of the TLS-handshake. I checked it with Wireshark.
Can you have a look at it. Thanks.
Yes, I'll have a look...
PS> If the proxy is an IP address, then no SNI can be used. SNI only makes sense when it's a domain name, not a numeric dotted IP address.
I dont know if you missunderstand me. I do not expect that the SNI is send at the connect to the HTTP proxy, but to the webserver behind the proxy.
https://bob.sni.velox.ch/ is a test page for SNI that is linked at wikipedia.
Without a http proxy is set the correct webpage bob.sni.velox.ch is called. With the put_ProxyDomain() the wrong page alice.sni.velox.ch is delivered by the webserver.
Thanks, but it is the proxy that establishes the SSL/TLS connection with the HTTP server. Therefore, it is the proxy software that must use SNI. Does the proxy seem to use SNI when a browser (FireFox) navigates to "https://bob.sni.velox.ch/" ? If so, and if Chilkat does not, then it can only be that there is some sort of information in the HTTP request that causes SNI to be used. I can't think of anything that would be different. I would fully expect Firefox to have the same behavior as Chilkat when going through a proxy, because neither Firefox or Chilkat are establishing the actual TLS connection with the web server.
If I use Firefox the connection to the correct website is established. Our HTTP proxy is the common product Squid proxy.
When a HTTPS connection is established via a proxy, the Firefox and Chilkat sends via HTTP a "CONNECT bob.sni.velox.ch 443" to the Squid. The Squid answers with a "HTTP/1.1 200 Connection establishedrn". After that the TLS handshake with "Client Hello" begins. The Firefox include a server_name extension and Chilkat client do not.
As far as I know Squid is not like a man-in-the-middle at a HTTPS-connection, but after the first CONNECT sends everything without change from the client to the webserver and reverse.
I send you the Wireshark Log from the test (only the relavant part) and the Chilkat DebugLog via Email to the support address.
Serras, ahhh yes! My mistake. I forgot. I'll take care of it..
The pre-release build is updated (same URL).
This should fix the HTTP proxy case. It also fixes the case for SOCKS proxies as well..