Problems with Thunderbird 38.0.1 and SSL

Dead Thunderbird
Version 38.0.1 of Thunderbird is an ex-mail client. It has ceased to be.

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.

 

Please generate and paste your ad code here. If left empty, the ad location will be highlighted on your blog pages with a reminder to enter your code. Mid-Post

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

 

Security certificates broken on Google Chrome 41

Don’t install the latest release of Google Chrome (41), released on Thursday (Friday UK time). They’ve messed up. Twice.

Broken SSL when talking to routers etc.

The first problem comes when accessing the web interface on a device such as a router over SSL (encrypted). Unfortunately, because the software in theses is embedded, the security certificate it uses isn’t going to match the name of the device you use to access it. This would be impossible – when it leaves the factory it hasn’t had its IP address assigned on your site; never mind the DNS entry. Previously browsers have allowed you to ignore this mis-match; the encryption works as long as you’re comfortable that you’re really talking what you think you are using some other check, and once the exception has been stored, this should be the end of the matter.

But not with Chrome release 41. Now it will show you the screen below:

ChromeMessedUp

If you ask for more details it doesn’t really give you much:

A secure connection cannot be established because this site uses an unsupported protocol.
Error code: ERR_SSL_VERSION_OR_CIPHER_MISMATCH
This comes from a DrayTek 2820 modem/router, but the problem seems to exist on other networking kit.

More adverts too – and a malware backdoor

(Please see update below – there may be an innocent explanation for this)
As an extra surprise, those nice people seem to have found a way of blocking URL keyword filters used to keep adverts out from objectionable sources, circumventing methods of blocking Google’s syndicated advertising. I’m still researching this, but the way they appear to have done it means that embedded content from other sources than the site you’re looking at is extremely difficult to block.
It appears Google has done this to protect its revenue stream from adverts, with little regard from the site policies that may exist for reasons Google may not realise. But that’s not the worst of it: how long will it be before this feature of Chrome is used for drive-by downloads. If you’re firewall isn’t able to cross-check the source of the content on a page, it can be coming from anywhere.
Unfortunately there is no way of rolling back a bad version of Chrome. They really don’t like you doing that, however dangerous a release might be.
I have, of course, made urgent representations to the Chrome project but we will have to wait and see. In the mean time, all I can suggest is that you prevent Chrome from updating beyond version 40.

Update 2015-03-23
On further investigation, the updated Chrome isn’t doing a DNS lookup to find the Google ad-server. I’m unsure whether this is because it somehow cached the DNS results internally or whether its hard-wired. It certainly wasn’t using the system cache, but I know Chrome has kept its own cache in the past. If it is from an internal cache, the mechanism used to get the IP address in there in the first place is a mystery, however Google’s ad servers change from time to time and it’s not impossible that the perimeter firewall simply hadn’t kept up and allowed some through.

My next research will be looking more closely at the DNS traffic.

Heartbleed bug not as widespread as thought

Having tested a few servers I’m involved with, many of which are using old or very old versions of OpenSSL, I can’t say I’ve found many with the problem. You can test a server here: http://filippo.io/Heartbleed/ on a site recommended by Bruce Schneier.

So what’s going on? Does this affect very specific nearly-new releases. This story could turn out to be a serious but solvable problem, and a media panic. I recall spending most of 1999 doing interviews on how the “year 2000 bug” was going to be a damp squib, but it’s early days yet.

Heartbleed bug

Someone’s finally found a serious bug in OpenSSL. It allows a remote attacker to snoop around in the processes memory, and this is seriously bad news because this is where you will find the private keys its using. They’re called “private keys” because, unlike public keys, they need to remain private.

This is going to affect most web sites using https, and secure email (if you’re using it – most aren’t). But before user’s rush off to change their passwords (which are different for each site, aren’t they?) – there’s no point in doing this if an attacker is watching. The popular press reckons your passwords are compromised; I don’t. If I understand it correctly, this exploit theoretically allows an attacker to intercept encrypted traffic by pretending to be someone else, and in doing so can read everything you send – including your password. So don’t log in until the server is fixed. They can’t read your password until you use it.

To cure this bug you need a new version of OpenSSL, which is going to be a complete PITA for server operators who aren’t on-site. Hell, it’ll be a PITA even if you are on-site with the servers. Once this is done you’ll also need new certificates, and the certificate authorities aren’t geared up for everyone in the world changing at once.

But the big fun one is when you can’t update OpenSSL. It’s used everywhere, including in embedded systems for which there was never any upgrade route. I’m talking routers, smart TVs – everythign.

I believe that SSH isn’t affected by this, which is one good thing, but I’m waiting for confirmation. Watch this space.

But, if you’re using a secure web site to log in over SSL, consider the password compromised if you’ve used it in the last few days and be prepared to change it soon.

Certificate “Errors” on Internet Explorer 9 – and how to stop them

Like recent versions of Internet Explorer, Version 9 has a Microsoft-style way of handling SSL certificates. It won’t let lusers access anything over a secure connection if there’s anything wrong with the certificate the remote end has presented. On the face of it, this is all very reasonable, as you don’t want the lusers being tricked by nasty criminals. But in reality it’s not as simple as that.

A bit of background, because everyone should make an informed choice about this…

SSL (or TLS) has two purposes – authentication and encryption. When you send data over SSL then two things occur. Firstly it’s only readable by the receiving computer (i.e. it’s encrypted), and secondly you know you’re talking to the right server (the link is authenticated – both computers recognise each other). The computers don’t exactly exchange passwords, but they have a way of recognising each other’s SSL certificate. Put simply, if two computers need to talk they have a copy of each other’s certificate stored on their disk  and they use to make sure they’re not talking to an impostor (gross over-simplification, but it’s a paradigm that works). Should one computer not have the certificate needed to authenticate the other end it will be supplied, and this is supplied certificate is checked to see if its “signed” by an “signing authority” using a certificate it does already have has. In other words, the unknown remote certificate arrives and the computer checks with a “signing authority” certificate to see if it’s been signed, and is therefore to be trusted. If it’s okay, it’s stored and used.

Now here’s where it breaks in Microsoft-land: For your computer’s certificate (the one it sends) to be signed by a “signing authority”, money has to change hands. Quite a lot of money, in fact. If it’s not signed, the recipient will have no way of knowing it’s really you.

In the rest of the world (where SSL came from), on receipt of an unknown certificate,  you’d see a message saying that the remote computer says it can be recognised using the supplied certificate, but I’ve never seen it before: Do we trust it? In most cases the answer would be “yes” and the two computers become known to each other on subsequent connections. It’s okay to do this – it’s normal. Something like this happens on Windows with Firefox and other browsers, but not, apparently, Internet Explorer. Not until you did a bit deeper, anyway. Actually, Internet Explorer 9 can be made to recognise unsigned security certificates, and here’s how.

First off, we really need to know what we’re about to do. What are the symptoms? The address bar goes red and you get a page saying there’s a problem with the certificate every time you visit a “site”. You can click on something to proceed anyway, but the implication is that you’re heading for your doom. The “error” message you see is normally for one of three reasons, and reading it might be enlightening. On a bad day you might get all three! But taking them in turn:

“The security certificate presented by this website was not issued by a trusted certificate authority.”

This just means that no one has paid to have this certificate signed by anyone of Microsoft’s liking. It may be a private company-wide certificate, or that belonging to a piece of network equipment such as a router. If it’s a web site belonging to your bank or an on-line shop, then you should be worried! Otherwise, if there’s a reason why someone isn’t paying to have their certificate approved (indirectly) by Microsoft, make your own decision as to whether you trust it.

So how do you get around it? Actually it’s pretty simple but Microsoft aren’t giving out any clues! The trick is to run Internet Explorer as Administrator (not just when logged in as Administrator).  In current versions of Windows you do this by right-clicking on IE in the start menu and selecting “Run as Administrator” from the pop-up menu. If you don’t, the following won’t work.

Go to the site who’s certificate you wish to import, and proceed to view the site in spite of the warnings. Then in the address bar you’ll see “Certificate error”. Click on this and you’ll see an option to “View Certificate”, and (assuming you’re in Administrator mode) there’s be a button the “General” tab to “Install Certificate”. Follow the prompts. For maximum effectiveness(!) choose the option to “Place all certificates in…” and browse to the “Trusted Root Certification Authorities”. This probably isn’t necessary in most cases, but if you do this it’ll cover you for pretty much every use. Your PC will happily accept anything from the remote machine hereafter; so make sure you’re importing the right certificate!

“The security certificate presented by this website has expired or is not yet valid.”

This means the certificate is out-of-date, or exceptionally, too new. In most cases encountering a certificate that isn’t valid suggests that your computer’s clock has reset itself to 1980. If this sounds plausible, just proceed to use the certificate anyway (there’s a clear option on the screen to do this). You’ll still get a scary red address bar, then it’s up to the server operator to fix this, but before you get on the ‘phone and give them what for, make sure you’re computer’s idea of the time and date is actually correct.

“The security certificate presented by this website was issued for a different website’s address”

This third case is a bit more tricky. Basically the name of the computer is embedded into the certificate, but you might be referring to it by another name (i.e. an alias). Or it could be using a pinched certificate. If you’re talking to a network router like a Draytek 2820 by going to its IP address and it’s giving you a built-in certificate, it would have no way of knowing what name or address the router is ultimately going end up on. The certificate is bound to be wrong in this respect. However, fishing around in the Internet Explorer options, under Advanced (and right down near the bottom) there’s a check-box – “Warn about certificate name mismatches”. Un-check it and it’ll stop squawking. Unfortunately it’s either on or off; you can’t set it to ignore a mis-match for particular names only. Because of the risk that someone might be impersonating your bank, you’d probably be best to leave this one checked and put up with the red warnings.

Final word of warning

Some people reading this will reckon this advice is reckless. Why circumvent a security feature? Simple – if the authentication part of SSL isn’t working you still want it for the encryption. In an ideal world everyone would have signed certificates so you can verify everything you talk and know it’s what it claims to be the first time you meet it. Subsequent visits will be authenticated with your newly installed certificate, so if something turns up impersonating it alter it’ll be detected. In the real world you probably want your data encrypted regardless. A signed certificate is better, but not that much better.

Hassling everyone over security certificates, as Microsoft is doing, may be justifiable on some levels, but as far as I’m concerned, anything that makes the use of encrypted data paths more difficult or expensive to use than they need be is a bad thing. They’re throwing the baby out with the bathwater.