here my code: mSocket = new mySSLSocket (derived from SSLSocket)
mSocket.Secure = true
mSocket.ConnectionType = SSLSocket.TLSv12
mSocket.Address = "<server address>"
mSocket.Port = 443
mSocket.Connect()
immediately calls the error event with error-code 102 (lost connection) on a server hosted by Strato.
If I call the same with a different server (not at Strato) I get my connection and successfully can issue my reuest.
I give you the curl output too, which works in both cases but doesn’t show any significant difference to me.
So what’s going on here? Are there some hidden client identifications which are filtered by a firewall?
Thanx for any help
Jörgy
curl -v -ssl https://<server address and path>/inst.php?ping=ping
* Adding handle: conn: 0x7ff6fc004000
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7ff6fc004000) send_pipe: 1, recv_pipe: 0
* About to connect() to <server address> port 443 (#0)
* Trying <server IP address>...
* Connected to <server address> (<server IP address>) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
* Server certificate: <server address>
* Server certificate: Symantec Basic DV SSL CA - G2
* Server certificate: VeriSign Universal Root Certification Authority
> GET /<path>/inst.php?ping=ping HTTP/1.1
> User-Agent: curl/7.30.0
> Host: <server address>
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Tue, 13 Dec 2016 16:24:50 GMT
* Server Apache/2.2.31 (Unix) is not blacklisted
< Server: Apache/2.2.31 (Unix)
< X-Powered-By: PHP/5.3.29
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< Pragma: no-cache
< Content-Type: text/html
< Set-Cookie: ASESS=agknjn57ltlk059ct09tbesuv1; path=/
< Transfer-Encoding: chunked
<
* Connection #0 to host <server address> left intact
curl -v https://<server address and path>/inst.php?ping=ping
* Adding handle: conn: 0x7fef3a00aa00
* Adding handle: send: 0
* Adding handle: recv: 0
* Curl_addHandleToPipeline: length: 1
* - Conn 0 (0x7fef3a00aa00) send_pipe: 1, recv_pipe: 0
* About to connect() to <server address> port 443 (#0)
* Trying <server IP address>...
* Connected to <server address> (<server IP address>) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
* Server certificate: <server address>
* Server certificate: Let's Encrypt Authority X3
* Server certificate: DST Root CA X3
> GET /<path>/inst.php?ping=ping HTTP/1.1
> User-Agent: curl/7.30.0
> Host: <server address>
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Tue, 13 Dec 2016 16:57:36 GMT
* Server Apache is not blacklisted
< Server: Apache
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
< Pragma: no-cache
< Set-Cookie: ASESS=u77084gr6f8v6qtdvgrd7a86c0; path=/
< X-Powered-By: PleskLin
< Vary: Accept-Encoding
< Transfer-Encoding: chunked
< Content-Type: text/html
<
* Connection #0 to host <server address> left intact
Ok folks, I still stick to this problem.
It seems to me, that already the SSL negotiation fails, because HTTPSecureSocket doesn’t send an appropriate “name” (or none) of the target host for “server name indication” (SNI). Strato of course gathers multiple https-Sites under one IP. To distinguish different certs their server needs to know the “name” of the name based virtual server.
In wireshark I get:
Alert (Level: Fatal, Description: Unrecognized Name)[/code] after my client says [code]Client Hello
Other Servers don’t have that problem.
Does anybody have a hint for me?
Scusi Julian, I didn’t get your point?
The two curl outputs both work. They only differ slightly. Towards my opinion, the difference isn’t the issue.
I’m analyzing the protocol level with wireshark and up to now I found out that the SNI extension is missing during handshake.
When HTTPSecureSocket sends its “Client Hello” it passes along its abilities, and there, compared with a call by a browser, the following extension is missing “Extension: server_name” or “Server Name Indication extension”!
The following lines show the working “Client Hello” sent by a browser:
Frame 4: 583 bytes on wire (4664 bits), 583 bytes captured (4664 bits) on interface 0
Ethernet II, Src: Apple_35:0c:d0 (a8:20:66:35:0c:d0), Dst: AvmAudio_1e:f5:e4 (38:10:d5:1e:f5:e4)
Internet Protocol Version 4, Src: 192.168.178.41, Dst: 81.169.145.82
Transmission Control Protocol, Src Port: 63730, Dst Port: 443, Seq: 1, Ack: 1, Len: 517
Secure Sockets Layer
TLSv1.2 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 512
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 508
Version: TLS 1.2 (0x0303)
Random
Session ID Length: 32
Session ID: 6cb10f518d9878779f0f9e12e300cea66f8b9537569d0d78...
Cipher Suites Length: 44
Cipher Suites (22 suites)
Compression Methods Length: 1
Compression Methods (1 method)
Extensions Length: 391
Extension: server_name
Type: server_name (0x0000)
Length: 28
Server Name Indication extension
Server Name list length: 26
Server Name Type: host_name (0)
Server Name length: 23
Server Name: www.focus-fotostudio.de
Extension: elliptic_curves
Extension: ec_point_formats
Extension: signature_algorithms
Extension: next_protocol_negotiation
Extension: Application Layer Protocol Negotiation
Extension: status_request
Extension: signed_certificate_timestamp
Extension: Padding
Yes, this is the Strato server.
I just updated Xojo to the newest version an recompile my testing app. Server Name Indication is still missing.
Here the “Client Hello” from my testing app:
ok so it is desktop, if you can, run a curl on the 1and1 server and post the details, it will confirm my theory without my having to continue with my example
There are two web hostings at Strato and 1and1 and my testing server running plesk and using let’s encrypt certs.
On this three “servers” I call a simple PHP-Script by HTTPSecureSocket.get() with my Xojo desktop apps.
With my own this works, but not with the others.
My initial hunch was to look into the certificates, it might be that you have errors from sites that host a " Let’s Encrypt Authority X3" cert with a root of “DST Root CA X3”. Xojo might not be utilising the “DST Root CA X3” correctly, some browsers/computer will require a Root Chain install.
No it’s definitifly not an issue about the certs. With my let’s encrypt certs it works fine.
It’s an issue with the servers. Strato and 1&1 expect this SNI extension to associate the appropriate cert with it.
But thanks for your thoughts.
I’m just sending Xojo a bug report. (Hasn’t there been a tool for this in former days? Can’t find it…)
How do you expect them to look into it when you provide nothing for them to test?
All you do it present them with some results, but nothing to even get there. A good report includes a test project as well as a working example of what works and what does not work, so that it can be compared by Xojo themselves.
Even if you tell them what they do wrong, they still need a way to test if a fix would work, so they still need something to test with and against.
Also, it’s not a regression unless you can prove that it used to work in a previous version of Xojo.
