I can’t connect to email servers using strong encryption, servers say “no shared cipher”. So, which cipher suites are available within em client?
Thanks, Robert
Hi Robert, not completely sure if I understand the issue, are you using security policies in your account settings for IMAP/SMTP?
Are you seeing any errors? Can you make a screenshot of such error and post it here on the forum?
Thank you,
Paul.
Hi Paul,
in em client, I only see that connection to the IMAP servers fails, the “Diagnosis” dialog also fails to “repair” things. In the server’s logs, I see that there’s no shared TLS cipher available. Our servers are configured to only accept strong encryption ciphers for IMAP and SMTP submission (port 587), especially only diffie-hellman key exchange algorithms.
I played around a bit and found that the strongest working cipher with em client is AES256-SHA, which is TLS1.0 without forward secrecy.
All TLS1.0 ciphers with forward secrecy (e.g. DHE-RSA-AES256-SHA) or TLS1.2 ciphers fail.
To me this looks like that em client neither supports forward secrecy, nor TLS1.2 for IMAP/SMTP connections.
This is, to be honest, by far behind today’s state of the art technology, and unacceptable.
It seems that em client is able to use forward secrecy and maybe TLS1.2 (didn’t check this thoroughly) for caldav connections. So, why not for IMAP/SMTP?
Also, em client is unable to connect to XMPP servers using STARTTLS on port 5222, only old fashioned SSL on port 5223 seems to be available.
I think there’s a lot to do for em client developpers…
Cheers,
Robert
Hi Robert, the support for TLS version only depends on the version of your .NET framework, try to update your .NET framework to it’s latest available version (4.5.2 at least) and check if the issue persists.
Thank you,
Paul.
Hi Paul,
thanks, I have a fresh Win 7 installation with all updates installed. Will check .NET Version later.
Cheers, Robert
Let us know if that helped the issue, or if you come across any other questions or issues, we’ll be happy to help.
Thank you,
Paul.
Okay, I followed the instructions in the MS Knowledge Base to determine
.NET version, and found it was 4.5.1, I then upgraded to 4.5.2, but this did not change the behaviour of emclient.
Whenever the servers are configured to offer forward secrecy ciphers only for IMAP/SMTP, emclient fails to connect, while all other (Linux and Android) clients I’ve tested so far support forward secrecy ciphers like DHE-RSA-AES256-SHA (TLS1.0) or even ECDHE-RSA-AES256-GCM-SHA384 (TLS1.2).
Now, AES256-SHA, which seems to be the strongest cipher used by emclient, is not too bad, but it lacks forward secrecy, and SHA1 must be considered as insecure nowadays.
Moreover, unlike all other email clients, emclient also fails to use other authentication methods than PLAIN (cleartext password). Neither CRAM-MD5, nor DIGEST-MD5 seem to be supported.
All this is even more incomprehensible, since emclient works like a charm with our caldav/carddav Apache server, which is configured exactly like the IMAP servers (meaning, mandatory forward secrecy and DIGEST-MD5 authentication).
From what I’ve seen so far, emclient is really a great piece of software with reasonable pricing, but with a number of security flaws. At least strong encryption with support for forward secrecy should be implemented, I am putting this on the whishlist 
Cheers, Robert
We are not directly in control of the TLS/SSL ciphers since they are implemented by the .NET Framework or the schannel library in Windows respectively. And we don’t plan to use 3rd-party implementation because of security concerns and potential vulnerability patching.
It is possible that IMAP behaves differently since we still target .NET Framework 2.0 for backwards compatibility. We have to explicitly list supported TLS versions for IMAP connections and thus the code may not tell the .NET Framework that TLS 1.1 and 1.2 is supported. We can look into that and modify the behavior for newer .NET versions.
As for authentication schemes we do support both CRAM-MD5 and DIGEST-MD5, but it depends on the order in which the server announces the authentication schemes. We generally try to avoid DIGEST-MD5 because it is poorly implemented in many servers and only results in unsuccessful round-trips and bogus error messages. In addition to that we also support NTLM and OTP authentication schemes.
This is a big issue. We enabled AES256-SHA just for em Client, which is a shame, because it doesn’t support Forward Secrecy. Would be great if this would get priority, especially with recent news about older crypto.
Hi, thank you for the suggestion, we’ll consider improving this for future releases of eM Client.
Thank you for understanding,
Paul.
Filip,
Is eM Client perchance using limilabs Mail.dll library?
If so, TLS protocols v1.1 and v1.2 should be supported so long as the underlying .net 4.5 library supports.
The only catch is that they must explicitly enabled via the “SSLConfiguration” and “EnabledSslProtocols” property names as per this support document: