Thunderbird used to be my mail client of choice, but suddenly I’m not so sure! The latest update on the release channel (version 38.0.1) seems to have broken completely when using self-signed certificates for SSL.
A self-signed certificate makes sense when you know you can trust it; otherwise you get a signing authority you do trust to verify your certificate (for loadsamoney). If you’re talking to your own servers, there’s not point in doing this as there are other ways to check you’re talking to who you think you are. Thunderbird used to warn you that it didn’t recognise a self-signed certificate the first time it saw it, but if you told it to go ahead anyway it would add it to the trusted list and go on encrypting your data for you quite happily.
Since “upgrading” to version 38 it suddenly stopped working. No more email. No more sending email. It just failed silently (that’s bad, for a start), the only clue was that I couldn’t send an email or copy it to the drafts folder.
On examining the logs at the server end I found stuff like this:
Jul 7 23:17:54 dovecot: imap-login: Disconnected (no auth attempts):
rip=###.###.###.###, lip=###.###.###.###, TLS handshaking: SSL_accept()
failed: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
Suspicious! So I turned off SSL in Thunderbird and it all worked again. This is NOT a sensible solution. Unfortunately, I have yet to solve this one, other to simply not upgrade Thunderbird beyond 31.7.
Fortunately, you can still download the previous non-beta version from here, (assuming Mozilla don’t move it). You actually want 31.7.0, because the intervening releases were betas, and 31.7.0 is as recent as May 2015 so it’s not ancient. Just navigate around the site you don’t want the English version. Simply install it everything comes back the way it used to be, or at least it did for me.
Update 15-Jul-2015:
It appears that Thunderbird may have decided not to accept TLS with less that 1024-bit DH keys without telling anyone. Even if they had mentioned it, there’s not a lot users can do with it. This means that if you’re using a 512-bit key (which is considered export-grade) then it’s going to refuse to talk. Worse than that, it doesn’t pop up a message saying WHY it’s not going to talk. It’s just going to fail the connection. Presumably, as my friend Graham put it, this indicates that the Thunderbird open-source developers are hoping to get a job with Apple.
I hope this nonsense will be resolved in 38.1! In the mean time, turn off auto-update.
Update 30-Jul-2015:
I’ve now updated the server certificates being in-date (which doesn’t actually matter), and made sure they were 1024-bit (which they were) and apart from upsetting everyone who has had to accept the new certificate, Thunderbird still barfs.
Update 15-Aug-2015:
It get’s worse – there has been an update to the 31.x branch to 31.8.0, and this has the same problem. Use the link above and make sure you’re using 31.7.0
One client machine which I keep up to date moved from 31.6 to 38.2 and all email ceased. I went straight to the travelling client machine and switched OFF automatic updates to Thunderbird. An update crept through under Firefox I suspect, and now that has stopped too. The solution that works is to open my IMAP on port 143 and my SMTP on port 25 instead of the other ports I was using – leaving my Mailserver a target. I am now working on enhancing my certificate exceptions in TB, but there is still more work to do with this. Ho Hum! (Linux Ubuntu 14.04 on both machines, Mercury 32 on Mail Server)
Hello Dick – small world if you’re having this problem too!
Actually, there’s more to tell. I’m working (in my copious spare time) with developers at Mozilla. In the mean time, there is a workaround – you need to install this:
https://addons.mozilla.org/en-us/firefox/addon/disable-dhe/
It’s billed as a Firefox add-on, but they share code and add-ons and it will allow later versions of Thunderbird to work (apparently).
Mozilla are absolutely convinced that 512 and 1024 bit Diffie-Hellman cyphers have to be eradicated because “Nation States” have the supercomputers necessary to crack them. I’ve given up arguing on that one, as they’re not backing down. The enigmatic error reporting by Thunderbird as it barfs on one of the “unworthy” certificates leaves a great deal to be desired; presumably they’re all angling for developer jobs at Apple.
One thing you probably don’t want to do on a live server is try using OpenSSL to generate a more secure replacement certificate. I’ve tried this, generating certificates to their published requirements, and it still doesn’t work and drives the users crazy. When I figure out the runes I’ll post an update, but I need to sort out a suitable test-bed first. This got eclipsed by Google’s disastrous security upgrade to GMail. http://blog.frankleonhardt.com/2015/gmail-cant-send-to-sendmail/
By all means give me a call if you need to know more.
Hi Frank
Been a busy week but Thunderbird 38.3 has arrived, and Mercury32 4.8 has arrived with stronger certificates! Just implemented both, and Thunderbird now allows me to create a Certificate Exception for my self-signed certificate. Back in business now with security back in place.
So, you appear to be using 64-bit Linux for your desktop but running a mail server on Windows. Most people do it the other way around. Very perverse.
I don’t think it’s the upgrade to Thunderbird that’s helped – I suspect Mercury may have generated certificates that are more to Thunderbird’s liking. I wish I knew why.
Having badgered Mozilla about this, I’ve had a reply. Apparently they dropped support for any certificate that wasn’t 2048 bit. In other words, in the fright over Edward Snowdon, only completely insane levels of encryption are going to be allowed.
The issue of the poor diagnostics needs to be dealt with, and I’m following this up with the developers. As far as I’m concerned, the encryption level of the certificates is the business of the operator of the mail server and it’s not the client’s place to enforce anything different. As Mozilla clearly feels that it is their place, I’m pushing for some useful diagnostic as to why a connection has been refused – i.e. the fact that it doesn’t like the certificate, and exectly WHAT about it that it doesn’t like.
I’m getting this same issue with 38.2.0. You?
Yes, it’s embeeded in the code moving forward. However, see next comment!
Well, after further hassle, I admit you’re right. I have downgraded to 31.7 and things work again. I have also turned off automatic updating. Thanks!