Possible TLS bug in mail.dll

0 votes

I'm experiencing issues in an application written using a C# Mail.dll library which I believe is yours.

Since the author of the application is MIA, I thought I'd report the exception to you in the hopes that you will have an interest in fixing the problem (assuming you didn't already do so!)

Please let me know if I am wrong; I don't have access to the source code.

The application is trying to connect to an IMAP server using TLS. The server is running Dovecot with SSLv2 and SSLv3 disabled. Dovecot's secure IMAP port does not support insecure authentication. As such, this port allows only TLS.

The server port has been tested using Mozilla Thunderbird from the same client, and is confirmed to be in good working order.

The application fails to connect ("times out"); By enabling debugging using old instructions I found from the developer, I was able to obtain this stack trace:

Error: 0 : Lesnikowski.Client.ServerException: 
Unable to read data from the transport connection: 
A connection attempt failed because the connected party did not 
properly respond 
after a period of time, or established connection failed because 
connected host has failed to respond
---> System.IO.IOException: Unable to read data from the transport connection:
A connection attempt failed because the connected party did not properly respond 
after a period of time, or established connection failed because connected host 
has failed to respond.
---> System.Net.Sockets.SocketException: A connection attempt failed because 
the connected party did not properly respond after a period of time, 
or established connection failed because connected host has failed to respond
   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset,
        Int32 size)
   --- End of inner exception stack trace ---
   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, 
        Int32 size)
   at System.IO.StreamReader.ReadBuffer()
   at System.IO.StreamReader.Read()
   at .()
   at .()
   --- End of inner exception stack trace ---
   at .()
   at .(StringBuilder )
   at Lesnikowski.Client.IMAP.ImapResponse.(TextReader )
   at Lesnikowski.Client.IMAP.Imap.GetServerGreeting()
   at Lesnikowski.Client.TcpTextClient.Connect(String host, Int32 port, Boolean useSSL)
   at ...application...-

What appears to be the problem here is that the server does not provide a greeting. Because the port isn't a hybrid TLS port as you might get for example in Exim (for SMTP), the server expects the client to start TLS right away. Would it be possible for Mail.dll to timeout faster, catch this exception and blunder on with TLS in this situation?

The application has a TLS and SSL setting; the SSL setting does not time out but fails explicitly.

DLL version: 3.0.11123.1722

by
edited by

1 Answer

0 votes

1.
Version 3.0.11123.1722 is from 2011, so it is very old. You can download the latest version here:
https://www.limilabs.com/mail/download

2.
Mail.dll supports SSL and TLS 1.1 and 1.2.

It is possible to set which protocols component allows and which shouldn't be used.

Application developer should provide an option to specify that.

3.
You are incorrect in your assessment of the bug.

When SSL tunnel is created both server and client negotiate which protocol versions are allowed. If server and email client aren't able to establish that, exception will be thrown by internal .NET SSL/TLS stream implementation.

If server performs successful SSL negotiation and afterwards when it sees SSL 3.0 instead of required TLS 1.2 it disconnects, it is acting incorrectly. Server shouldn't allow SSL 3.0 tunnel to be created in the first place.

4.
Most likely the TLS setting in the app is for explicit SSL/TLS aka StartTLS and not for TLS 1.1 or TLS1.2 protocol versions (SSL vs TLS vs STARTTLS: https://www.limilabs.com/blog/ssl-vs-tls-vs-starttls-stls). This is probably why you are confused.

by (301k points)
...