|
Author | Secure SMTP/POP3 e-mail via office365.com (using Synapse) |
Dany Marmur 2017-09-05 15:53:48 Registered user |
I have put up test where i can get a connection refused if i do not load root certs in my client. If i load the certs i get information on the certificate chain and can connect. This is built from a combination of the Demos.
I have been able to sucessfully POP3, SMTP using SSL and SMTP using AutoTLS to my gmail account! I have been able to sucessfully POP3 to outlook.office365.com using SSL. I cannot connect to smtp.office365.com using AutoTLS. (SSL is not supported and of course gives a timeout). Connection using AutoTLS gives "Outgoing fatal alert 50 decode_error:". Anyone had similar problems? Any hint would be appreciated. And i can come back with more information. Regards, /Dany |
Henrick Wibell Hellström 2017-09-06 05:42:50 Registered user |
A "fatal alert 50 decode_error" is typically indicative of underlying implementation issues, such as incompatible interpretations of standards, memory allocation issues, etc. If the alert is outgoing, it means that your client implementation end detected inconsistencies in the encoding of the protocol messages sent by the remote server.
The error code will be set somewhere in unit StreamSec.Mobile.TlsLayer. Since the error could be triggered by a wide variety of causes, it might help if you could pin-point the exact line where it occurs. |
Dany Marmur 2017-09-06 12:56:47 Registered user |
That is not very difficult. The tricky part is figuring out why :)
1. The call to FSock.SSLDoConnect is skipped in TSMTPSend.Connect since this server only provides AutoTLS. 2. In TSMTPSend StartTLS is called since the server responds with the capabiblity 'STARTTLS'. 3. TCPBlockSocket.SSLDoConnect calls TSSLStreamSec4.Connect. 4. There is a while loop testing for encryption here. And it is on the /second pass/ FLastError <> 0 immediately after the call to SSLCheck. First call to TTLS_ContentLayer.Connect (before the while) creates FHandshakes. First call to RawSend result is 188 (not SOCKET_ERROR). First test on TTLS_ContentLayer.GetEncrypted both assigned tests have nil arguments and FHandshakes.Done is false. First call to RawRecv returns a size (not SOCKET_ERROR). After the first call to FClient.DecodeData outstrm.Position > 0 so RawSend is called. Second test on TTLS_ContentLayer.GetEncrypted same as above (!). Second call to TSSLStreamSec4.SSLCheck the FClient.LastAlertCode is 50. I can trace deeper if i know what is of interest. HTH, /D |
Henrick Wibell Hellström 2017-09-06 14:00:05 Registered user |
Unfortunately, yes, you have to trace deeper: Search for any assignment ":= decode_error;" in the unit I mentioned (StreamSec.Mobile.TlsLayer). Place a break point on each occurrence. Run. See which break point is first to be triggered.
|
Dany Marmur 2017-09-07 08:14:21 Registered user |
Hmm... yes, i can see how that was kind of useless.
Here is the callstack when hitting the breakpoint: StreamSec.Mobile.TlsLayer.TTLS_HandshakeProtocol.HandleServerCertReq($19F1C4,1700296,$8A83430) StreamSec.Mobile.TlsLayer.TTLS_HandshakeProtocol.Add($385FA00,26,$8A83430) StreamSec.Mobile.TlsLayer.TTLS_ContentLayer.HandleHandshake($8A83430) StreamSec.Mobile.TlsLayer.TTLS_ContentLayer.DecodeData($8A83250,$8A83170,$8A83430) SSL_StreamSec4.TSSLStreamSec4.Connect ... FSignAlg = asRSA and TLS_DecodeCertificateRequest returns false. Result in TLS_DecodeCertificateRequest becomes false on the first execution of line 3055 [Result := RS.Read(AsPtr(F)^,W) = W;] |
Henrick Wibell Hellström 2017-09-07 09:11:43 Registered user |
That was very helpful, thanks, I think I can make this work, but it requires an update. Please keep posted.
|
Dany Marmur 2017-09-07 09:19:20 Registered user |
Sure.
|
Henrick Wibell Hellström 2017-09-08 09:05:06 Registered user |
Issue resolved in Release 4.0.1.321 (2017 September 8).
The issue was caused by a ST 4.0 bug, with client side decoding of TLS 1.2 client certificate request handshake messages. Another thing I discovered while running the test case you provided, is that the SSL_StreamSec4 implementation will not call TLSSetupClient. This is a call your program has to make, prior to calling Login on the Ararat Synapse TSMTPSend instance. This is in particular important if you wish to disable the RequireClientCertificate option. |
Dany Marmur 2017-09-08 09:15:43 Registered user |
Brilliant! I'll update now and confirm later.
Yes, i noticed, "implicit" start of client TLS will not work properly. In my real-world implementation there's a lot of prerequisities and settings and startup and shutdown is "orchestrated". Thanks! /Dany |
Dany Marmur 2017-09-08 12:29:02 Registered user |
All confirmed.
/D |
Henrick Wibell Hellström 2017-09-08 13:39:29 Registered user |
Great!
|