SSLSocket.SSLv23 not working as advertised

Hello,
(Catalina; Xojo 2019.r1.1 and 2.2.1; I can’t test with Mojave or earlier system versions)

Xojo docs about SSLSocket.SSLv23:

In fact I have always used SSLv23 successfully for several gmail, yahoo etc. accounts. Until I faced failure with @icloud.com accounts when sending messages.

From my tests, SMTPsock.ConnectionType = SSLSocket.SSLv23 fails to deliver messages, while using SMTPsock.ConnectionType = SSLSocket.TLSv12 the message gets set. So, at present, using a @icloud.com account, I can successfully send messages only with this configuration:

SMTPsock.Address = "smtp.mail.me.com" SMTPsock.secure = true SMTPSock.port = 587 SMTPsock.SMTPConnectionMode = 0 SMTPsock.ConnectionType = SSLSocket.TLSv12//or TLSv1 or TLSv11

Any idea why SMTPsock.ConnectionType = SSLSocket.SSLv23 does not pick up SSLSocket.TLSv1, TLSv11 or TLSv12?

Regards.

Edit: OK with SMTPsock.ConnectionType = SSLSocket.TLSv1, TLSv11 and TLSv12

Yes most cloud providers are forcing TLS1.1/1.2 which is good. SSLv23 is older and less secure.

The issue being that SSLv23 should auto pick up TLS, if I understand the docs correctly.

Maybe something to do with mode STARTTLS?
http://documentation.xojo.com/api/networking/smtpsecuresocket.html#smtpsecuresocket-smtpconnectiontypes

You are setting the wrong type perhaps. See the link and constants.

@Derk Jochems: [quote]Maybe something to do with mode STARTTLS?[/quote]

I tried all possible combinations (mode and ports), but at the end, only TLS made a difference (that is, it’d send the mail).

[quote=474779:@Carlo Rubini]@Derk Jochems:

I tried all possible combinations (mode and ports), but at the end, only TLS made a difference (that is, it’d send the mail).[/quote]
Strange. Maybe a bug, file a bugreport:

You do understand the docs correctly. But perhaps the other end didn’t want to negotiate.

SSLv23 requests the server negotiate the encryption protocol and cipher the connection should use. I just checked the server in your orignal post and it does not appear to want to negotiate anything.

Not a bug in Xojo. A choice made by the mail system administrator who configured the server. It is becoming more common with the big free mail box providers. Turning off negotiation makes it a little bit more difficult for the spammers and can save a significant amount on the electric bill for servers churning thousands of connections per second.

Thank you all for your comments and suggestions. Moving from SSLv23 to explicit TLS.

I’d suggest Xojo docs should include this piece of info as as possible negative problem when using SSLv23.

@Matthew Stevens: [quote]I just checked the server in your orignal post and it does not appear to want to negotiate anything[/quote]
Out of curiosity, would it be possible to know how you checked the server?

Presumably, then, using anything other than SSLv23 means that you have to specify a particular version of TLS. Which means that you have to know, for each remote end, which particular version to use.

For my accounts (icloud.com, gmail, yahoo, fastmail) all the three TLS versions available in Xojo work OK.

I think others mentioned this above which is correct - the server side may not auto negotiate with your software - You must be responsible to write your code to possibly start w/ either TLS / SSLv23 and then be able to back off via the Error event and retry the next version type.

@Mike Cotrone: [quote]start w/ either TLS / SSLv23 and then be able to back off via the Error event[/quote]

Thank you for the suggestion. I had never thought of it!

Are Xojo responsible for telling me how to interface with a particular sensor connected to me RasPi?

When I was first asked to upgrade a webserver to TLSv1.2 there was little information out there and I had to turn to some very long and boring technical documents to get my head around the issues. These days there are plenty of less intimidating articles on the general IT and specialised network technology sites. If you have not visited SSL Labs, you should.

TL;DR All versions of SSL/TLS prior to version 1.2 are considered broken. AES-CBC ciphers are effectively deprecated and RSA keys should be no less than 2048 bits.

SSL/TLS encryption versions have been a moving target for some time now. The confusion tends to arise from system admins (or their business managers) being reticent to cut off ancient versions of client software. The big push to TLSv1.2 happened a couple years back when the big online payment gateways stopped accepting SSL3/TLSv1 connections.

[quote]@Matthew Stevens:
Out of curiosity, would it be possible to know how you checked the server?[/quote]
My goto tool for diagnosing e-mail issues is curl. Not sure where the version on my (Mojave) iMac came from - could be Apple, could be built from source. Open terminal, type curl --help, see what happens. For SSL/TLS issues in particular I tend to use the OpenSSL tools directly.

@Matthew Stevens: Thank you for the info.