CloudFlare responding weird to TLS1.2 HTTPSecureSocket

Hi I found a Xojo dev with this same problem back in May where you send a TLS1.2 handshake request and you get a TLS1.0 failure message. Our Cloudflare instance works fine with curl using TLS1.2.

Any thoughts on this and especially if you were the author above on the cloudflare issue?

What did you do to solve this? I am using wireshark and it confirms this issue still.

Im using Xojo 2019 r3.2

Httpsocket and httpsecuresocket are old and as far as i know deprecated.
Use URLConnection of you can

SSLSocket is not deprecated and HTTPSecureSocket uses SSLSocket.


It says so here so xojo deprecated it… probably because it’s http 1.0

For this thread - whatever (see my edit above) – please don’t hijack this thread as i NEED to find the answer to the OP.

We can debate this on the other thread.

You might wanna check their docs. It clearly states they only support http1.1 and later…

Connections from Cloudflare’s Edge to your origin server(s) only support HTTP/1.1. HTTP/2 and HTTP/3 accelerate page load and are free for all Cloudflare plans. HTTP/2 is enabled by default and requires an SSL certificate at Cloudflare’s edge network. Configure HTTP/2 and HTTP/3 via the Cloudflare Network app.

It’s not HTTP to blame @DerkJ. This is a TLS issue before HTTP even comes into play.

@Mike_Cotrone I’m thinking there is a cipher suite mismatch. I’m trying to find more information now.

@DerkJ thanks but – I already have been through their docs (I control the CloudFlare instance) – CURL works with it via TLS1.2 --> I use TLS1.2 with HTTPSecureSocket a ton with other APIs we write to. (I even tried the SSLv23 type and still gets a 102).

That could be but the request may be dropped if it doesn’t comply somewhere. The easiest thing would be to use some class that is supported.

Its not dropped its denied in a failure handshake response

I clearly Send a TLS 1.2 request:

The response is TLS 1.0 failure – Weird.

Curl Works like a champ:

Any of this:

While I agree that there probably won’t be a solution to this, there nothing easy about switching to a modern socket for legacy customers.

Yeah i know, but do you actually believe there will be support for legacy encryption? Or even legacy sockets? Maybe best to ask which route Xojo will go in this. There is nothing about ciphers used in the xojo docs…

I use modern API’s such as QuickBooks Online, DropBox, Google, MailChimp, etc. All no issues with HTTPSecureSocket using TLS1.2.

This issue appears to be unique to CloudFlare.

Can you compare the cipher suits they have with what cloudflare requires?


Xojo Offers (TLS1.2)


1 Like

Xojo steps down from 1.2 to 1.1 to 1.0 etc if you use a specific connectiontype did you try if it makes a differnece?

I only use specific connection types as alot of the Servers wont negotiate or step down (automatically). I have tried ALL Xojo types to no avail.

Do you seen any of the errors here perhaps? It’s probably a bug in the httpsecuresocket but what the bug could be…

@Mike_Cotrone You really shouldn’t be using HTTPSecureSocket these days. You will be bitten in the future. If you migrate now, your customers will be supported for much longer and you won’t be rushing to issue an update when it happens. Even now Apple is starting to require HTTP/2 for some requests. Don’t expect HTTP/1.0 to carry you for much longer. One or two years, I’d guess.

Cipher suites do match up. Unless I’m mistaken, the handshake should be using TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256.

Are we sure SSLSocket supports SNI? I think it does, but I’m not seeing any other potential reason for the failure.