SMTPSecureSocket not using TLS 1.2?

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://documentation.xojo.com/api/networking/sslsocket.html#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://documentation.xojo.com/api/networking/smtpsecuresocket.html#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_Araujo 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.

Well, this deserves a minimalist sample code with a messagebox at SMTPSecureSocket.ServerError event handler when finding SSLConnectionType <> 5 after a break (to see the bug in a build), attached to a FB case.

Tip: Checking the SMTP TLS 1.2 connection FROM the client endpoint:

If openssl does it ok, Xojo should too. If OpenSSL fails, inspect the reasons.

User@Mac ~ %  openssl s_client -starttls smtp -connect smtp.office365.com:587 -tls1_2

CONNECTED(0000019C)

Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1:RSA+SHA512:ECDSA+SHA512
Shared Requested Signature Algorithms: RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA1:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA1:DSA+SHA1:RSA+SHA512:ECDSA+SHA512
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: ECDH, P-384, 384 bits
---
SSL handshake has read 4405 bytes and written 424 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    PSK identity: None
    SRP username: None
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: yes
---
250 SMTPUTF8
^C
User@Mac ~ % 

Interestingly, I see a difference in my BigSur VM

--- These lines I got from from my openssl in windows that says:

CONNECTED(0000019C)

New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384

--- Are shown as this in my BigSur: 

CONNECTED(00000005)

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384

--- But the rest is almost the same:

SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384

I got this for our remote server, it looks like it’s using TLS 1.2 to me… :confused:

---
SSL handshake has read 4383 bytes and written 418 bytes
Verification: OK
---

SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384

Yep. At the end, you basically need to check these 2 values:

Did anyone find a solution to this problem?

I can also confirm SSLConnectionType=5 when composing mail. When Office365 randomly accepts or declines my mail, SSLConnectionType=3 (Breakpoint at MessageSent / ServerError)

Building using OS X 10.14 Xojo 2021R3.1
Clients using Windows with same problem

SSL-Session:
Protocol : TLSv1.2
Verify return code: 0 (ok)

Over 50% of mail transmissions fails with 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 New opt-in endpoint available for SMTP AUTH clients still needing legacy TLS - Microsoft Tech Community.

I hope there is a solution soon. It looks like Office365 is now always rejecting with that error message even though our email client app is set for TLSv12. (Windows 10 and macOS tested)

Use OAuth? I already have requests to support OAuth for Office 365.

Does anyone have it working with CURL MBS plugin? I’ve tried the send email examples and tried adding the SSL version number to use (d.OptionSSLVersion = d.kSSLVersionTLSv12 and d.OptionFTPSSL = d.kSSLVersionTLSv12) but it always comes back with an error saying TLSv1.3 wrong version number
Error log below
TLSv1.3 (OUT), TLS handshake, Client hello (1):
…(some garbage chars)
error:1408F10B:SSL routines:ssl3_get_record:wrong version number
Closing connection 0