SMTPSecureSocket not using TLS 1.2?

Targets Web
21

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.

22

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
23

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
24

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

25

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.

26

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)

27

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

28

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

29

What do you get when you run curl from the CLI? Like:

curl smtp.office365.com:587 --verbose --tlsv1.2

30

I got this

EHLO mymacbookpro
< 250-DM6PR12CA0036.outlook.office365.com Hello [96.3.67.23]
< 250-SIZE 157286400
< 250-PIPELINING
< 250-DSN
< 250-ENHANCEDSTATUSCODES
< 250-STARTTLS
< 250-8BITMIME
< 250-BINARYMIME
< 250-CHUNKING
< 250 SMTPUTF8
HELP
< 214-This server supports the following commands:
214-This server supports the following commands:
< 214 HELO EHLO STARTTLS RCPT DATA RSET MAIL QUIT HELP AUTH BDAT
214 HELO EHLO STARTTLS RCPT DATA RSET MAIL QUIT HELP AUTH BDAT

31

Well, curl is ok from your endpoint. An updated CURL MBS plugin should work from your endpoint…

32

I resolved my immediate issue now by changing the settings to use the “legacy” TLS protocols (used PowerShell and set the AllowLegacyTLSClients)
https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/opt-in-exchange-online-endpoint-for-legacy-tls-using-smtp-auth

33

Hello, All. Does anyone have an update on this issue or are we going to have to do the opt-in the legacy enpoint for now?

Thanks,
Rocky Scofield

34

We had to dump resources into switching to a transactional mail service. Luckily, I had already written most of the code necessary.

Edit: fixed link to github

35

Thanks for the prompt reply, Tim.

So, Xojo has been mum on this topic still, huh?

Rocky

36

I never opened a ticket because of their behavior regarding feedback cases lately. I try not to cause too much of a ruckus, so I’ll refrain from details.

I don’t expect to see this fixed on Xojo’s part.

37

I have it working with CURL MBS v.20.3. Christian helped with the options.
OptionPort is 587
OptionUseSSL is 3 for require encryption
OptionSSLVersion is 6 for TLS v1.2
OptionLoginOptions is “AUTH=LOGIN”
UseSSL = false

38

Sorry I missed this topic back when I ran into this issue. I too had to switch to using CURL MBS to resolve this issue.

39

I created a bug report 3 months ago. <https://xojo.com/issue/67590> with lots of detailed info. I got it closed. (Usually, I no longer waste my time filling reports. 20 years ago it was friendly and you got things fixed. Nowadays it is all the opposite).

40

Thanks for bumping the feedback ticket. It was my fear they were going to ask for a sample project, when that’s not really the problem. Hopefully they’ll gather the information from this thread and understand.