SMTPSecureSocket not using TLS 1.2?

Web 2.0 / API 2.0
Xojo Version: 2021r3.1
Server: Linux Ubuntu 20.04

I have a SMTPSecureSocket where we set SMTPSocket.SSLConnectionType = SSLSocket.SSLConnectionTypes.TLSv12

However, Microsoft Office 365 is rejecting a small number of connections that aren’t using TLS 1.2 as they phase out support for the older versions. On occasion, I get a send failure with the error message:

421 4.7.66 TLS 1.0 and 1.1 are not supported. Please upgrade/update your client to support TLS 1.2. Visit https://aka.ms/smtp_auth_tls.

I can’t reproduce it regularly, because Microsoft is only rejecting a small number of connections for now.

Has anyone else seen this?
Is there reason to believe Xojo SMTPSecureSocket is not using TLS 1.2 for some reason?
Is it limited to Linux deployment?

Are you sure those are coming from your SMTPSecureSocket since it could also be some system got your password. We’ve has such messages also, but not on Xojo’s smtp sockets (when someone tried logging in with stolen details).
Check the email here: https://haveibeenpwned.com to make sure.

Or maybe xojo has a fallback even if you set it to tlsv1.2 that’s not documented ?

Yes, the way the message logs it can only be coming from the SMTPSecureSocket.

This is a SMTPSecureSocket subclass, and the connection details are set in the constructor like this:

Public Sub Constructor()
  // Calling the overridden superclass constructor.
  // Note that this may need modifications if there are multiple constructor choices.
  // Possible constructor calls:
  // Constructor() -- From TCPSocket
  // Constructor() -- From SocketCore
  Super.Constructor
  
  // Setup connection details
  me.Address = "smtp.office365.com"
  me.Port = 587
  me.SSLEnabled = True
  me.SSLConnectionType = SSLConnectionTypes.TLSv12
  me.SMTPConnectionType = SMTPConnectionTypes.STARTTLS
  me.Username = ""
  me.Password = ""
  
End Sub

My concern is that the Xojo implementation isn’t communicating correctly for some reason and that when Microsoft shuts off support for the older protocols the web app will no longer be able to send anything. The current interrupts are already causing a problem.

I see now. On the microsoft website it’s explained that if a certificate in the chain is unverifyable or has an invalid hash you may encounter such error.

Perhaps the cert chain is not readable some times?

Do note that we have issues with microsoft servers alot more than other services. For example alot of (non-spam) is marked as spam even if proven otherwise. I couldn’t find any other about this disconnection issue… maybe they ran out of connections :sweat_smile:

Hi Tim -

We are starting to see this same issue as well with Office 365 as of about 2 weeks ago.

We are using XOJO2021 R3 in a Desktop Application on a Windows 10 and seeing the same behavior.

I’m with you it doesn’t appear to select and use TLS1.2 when sending the email even though our application is set to send it. It feels like that it is reverting to or defaulting to TLS 1.0.

Thanks!

1 Like

Can someone check if 2021r1.1 presents this bug, or it was introduced later, or we are living with a fake TLS 1.2 for some time? If Microsoft is correct, this alone deserves a 2021r3.2 release.

The office is now closed for the holiday but this issue is important to me. I was going to wait to make a ticket and email them until Monday in January when they reopen.

I’ve been poking today and I’m able to reproduce this even debugging locally. For some reason the debugger is showing SSLConnectionType as TLSv1 = 3 even though the property has been set to SSLConnectionTypes.TLSv12 as demonstrated above.

How about when you set SSLEnabled = True as last?

Isn’t that down to the negotiation? AIUI, one should always set it to .TLSv12 and then the two sides negotiate about what to use.

EDIT: actually I see this in my code:


me.SSLConnectionType = SSLSocket.SSLConnectionTypes.SSLv23     // This will start at TLSv12 and work down.
1 Like

At the break of this test, I see 5, as it should, from here.

Dim con As new SMTPSecureSocket
con.Address = "smtp.office365.com"
con.Port = 587
con.SSLEnabled = True
con.SSLConnectionType = SMTPSecureSocket.SSLConnectionTypes.TLSv12
con.SMTPConnectionType = SMTPSecureSocket.SMTPConnectionTypes.STARTTLS
con.Username = ""
con.Password = ""
con.Connect
break

@Tim_Parnell

New submission error speedbump to be introduced in O365

You should capture a transmission and check tls version. In wireshark Filter is ‘ssl.record.version == 0x0303’.

Versions:

  • 0x0300 SSL 3.0
  • 0x0301 TLS 1.0
  • 0x0302 TLS 1.1
  • 0x0303 TLS 1.2

Edit: added Versions

Can I point you all here:

https://docs.xojo.com/SSLSocket.SSLConnectionTypes

read what it says about SSLv23.

1 Like

The error is clearly telling that tls v1.2 is required. And @Tim_Parnell has it setup like that. Only xojo may give the correct answer or you can wireshark the connection and try an findout what’s happening.

@Tim_Parnell does this make a difference?

Dim con As new SMTPSecureSocket
con.Address = "smtp.office365.com"
con.Port = 587
con.Username = ""
con.Password = ""
con.SSLConnectionType = SMTPSecureSocket.SSLConnectionTypes.TLSv12
con.SMTPConnectionType = SMTPSecureSocket.SMTPConnectionTypes.STARTTLS
con.SSLEnabled = True
// Create an email message, use the SendMail method only. Don't call .Connect
break

How about the email headers, are they confirming tlsv1.2 ?

And if you use SSLv23, and both sides want TLSv1.2, then TLSv1.2 is what you will get. But you are including the posssiblity of negotiating downwards if one side does not support TLSv1.2.

Microsoft will probably just work with TLSv1 or TLSV1.1 since i see it’s working mostly. I think their server have some odd setup or are not all conigured correctly but since they also support TLSV1.2 they should just connect.

This could be a xojo issue. Is there a reason why you call .Connect we never call .Connect on the SMTPSecureSocket since that’s done by the .SendMail method
http://docs.xojo.com/SMTPSecureSocket.SendMail

I don’t use .SendMail.

@DerkJ check my post from microsoft.


With this in mind, starting in September 2021, we will reject a small percentage of connections that use TLS1.0 for SMTP AUTH. Clients should retry as with any other temporary errors that can occur during submission. Over time we will increase the percentage of rejected connections, causing delays in sending that more and more customers should notice. The error will be:

421 4.7.66 TLS 1.0 and 1.1 are not supported. Please upgrade/update your client to support TLS 1.2. Visit New opt-in endpoint available for SMTP AUTH clients still needing legacy TLS - Microsoft Tech Community.

And my test above, set up to use TLS1.2, does it as expected. The connection is completed, and the protocol is 5 (TLS1.2) instead of auto-downgraded to 3 (as Tim found in his tests).

But… I did it using Windows and 2021R3.1

And I believe Tim P. was testing it using Linux, if this is confirmed, Xojo Linux (or Tim’s Linux environment) may have a problem.

I have Microsoft Windows clients that had problems. The cases varies, but there are 3 fixes, sometimes they need to change the smtp server endpoint in my config to smtp.office365.com because they were using some Microsoft endpoint that Microsoft retired in favor of smtp.office365.com, or they need to set the protocol to TLS 1.2, or a mix of both.

I don’t have a Linux client using it, so I have no experience in SMTP cases isolated to that platform, and it MAY be the case here.

@Andreas_Reichmann Thanks for the link. I do want to find out why SMTPSecureSocket isn’t using TLS 1.2 rather than switch to a legacy endpoint.

@DerkJ Changing the order so SSLEnabled is last did not help. Email headers, when received, show TLS 1.2 as the connection type… I think? Adding a Connect before SendMail did not help.

@Rick_A I was able to reproduce the issue on macOS 11.6.1 in debug mode. The breakpoint is set in the SMTPSecureSocket.ServerError event handler. When that breakpoint is reached that’s when the SSLConnectionType is TLS1 = 3.

Forum for Xojo Programming Language and IDE. Copyright © 2021 Xojo, Inc.