SSLSocket doesn't like Strato Hosting Server

MacOS X, Xojo 2016 R4.1

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

I bet the port is closed.

Did the bottom one fail?

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?

From memory I had the answer waiting for you, but you didnt answer my question so I assumed you found the solution.

Out of your two curl examples, was it the bottom one that failed?

I know the curl examples work, but is the server from the 2nd curl post the one that fails?

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

Is the 2nd curl output from your Strato server?

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:

Frame 4: 363 bytes on wire (2904 bits), 363 bytes captured (2904 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: 52469, Dst Port: 443, Seq: 1, Ack: 1, Len: 297 Secure Sockets Layer TLSv1.2 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 292 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 288 Version: TLS 1.2 (0x0303) Random Session ID Length: 0 Cipher Suites Length: 138 Cipher Suites (69 suites) Compression Methods Length: 1 Compression Methods (1 method) Extensions Length: 109 Extension: ec_point_formats Extension: elliptic_curves Extension: SessionTicket TLS Extension: signature_algorithms Extension: Heartbeat

ok, is the code running on your machine, or on the xojo cloud?

The pity is, I just got the complaint, that my software isn’t working against 1und1 servers neither :-((

I think I will post a bug now…

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.

I only run the curl samples to get some infos about the headers “normally” used. But this doesn’t help.
So I start diving into the protocol itself.

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.

https://www.identrust.com/certificates/trustid/root-download-x3.html

Also make sure that the clients and servers time/dates are close and not far apart. If the time is incorrect on a client PC you will get SSL issues.

These might or might not be the problem, good luck finding out :slight_smile:

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…)

Ahh cool.

http://www.xojo.com/download/extras.php - look under Feedback

[quote=307398:@JulianS]Ahh cool.

http://www.xojo.com/download/extras.php - look under Feedback[/quote]

Thanx!

I posted a new bug case in “feedback” no. 46495 on 1/4/2017.
Still no reaction from Xojo yet.

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.

Use the new Frameworks xojo.net.httpsocket that supports SNI and works with 1und1 and Strato Virtual-HTTPS-Hosting