The Heartbleed bug has caused quite a stir. Mass media seems to be focussing on convincing you to change your passwords (and rightly so). But relatively few seem to be mentioning certificate revocation. Well if you’ve paid attention and are working through changing your passwords, then listen up – because you’re not done yet.
As we all know thanks to some genius explanations
, Heartbleed reveals the contents of a server’s memory. That memory might contain garbage, or passwords, or the server’s private certificate used for encryption. In fact, during one of the tests done during the early days of Heartbleed discovery (as well as in subsequent tests
), that memory did in fact contain the server’s private certificate.
So how does that affect you?
Certificates carry an expiry date. Once the certificate has expired, it will not be trusted by your browser for securing a connection. Otherwise, your browser will trust it, and will show you a nice little padlock icon once the connection is encrypted. Happy that the connection is secure, you begin doing your thing. Whether entering your password, or your credit card, or filing your Income Tax, that little padlock gives you the confidence that nobody can decrypt that transmission except the server. Not anybody sitting around you in Starbucks, and certainly not any actual bad guys.
Except you’ve been fooled. The bad guys somehow redirected your traffic to their server, where they presented your browser with the legitimate server’s legitimate private key (that they previously stole via the Heartbleed bug)! Perhaps they setup a wireless network at Starbucks and tricked you into connecting to it, or perhaps they were more nefarious than that. However they did it, you now have a fantastically secure connection to the wrong server! Thinking it’s the right server, you happily divulge your password, or your credit card, or you even your Income Tax forms… to the bad guys!
So how do we deal with this? Certificate revocation.
Remember above, where I said that once a certificate has expired, your browser will no longer trust it? Revoking a certificate is a way to force it to expire early. The revocation goes into a list, and your browser (or app) should check that list before securing the connection.
Except it doesn’t. And this is where the story gets a bit dire.
First, many admins who have been patching their servers to fix OpenSSL/Heartbleed, and who have even acquired new certificates, are failing to issue a certificate revocation
. This is a crucial step, and I implore any responsible server admins reading this to do so immediately.
Second, many browsers and apps do not check
for revocation, and those that do “soft fail” if they can’t connect to one of these revocation lists. In other words, if they can’t determine revocation status for a site for whatever reason, they will trust
the server’s certificate by default
. In fact, this is the reason some admins give
for not issuing revocation certificates in the first place. Regardless, this is the system we have. So we need to make the most of it. Perhaps Heartbleed will give us the incentive to build something better
So what can you do? You should do anything that you can to ensure that your browsers check for certificate revocation
, and that they do so strictly. You won’t be able to configure this in your mobile apps, or even in your mobile browsers. In fact, it might be best to avoid using mobile browsers for any secure connections for the next few months. But on the desktop, we can enable this setting in all major browsers, which I’ll describe below.
The reason we want “strict” checking is to avoid the “default trust” I was talking about above. So let’s continue to imagine that you have connected to a compromised network (you’re still at Starbucks, so at least you’re enjoying a nice hot coffee), and you’ve established a secure connection to the bad guy’s server. Your browser tries to connect to the certificate revocation list, but the bad guys have blocked that on their network. After trying for a few seconds, your browser eventually gives up since it can’t reach it. Not knowing whether the bad guy’s server’s certificate has been revoked or not, the browser trusts it by default. You get your padlock, and you divulge your password, your credit card, or your tax return.
This is exactly the wrong kind of behaviour we want from a browser in the wake of Heartbleed.
Default distrust is what we want right now. So tell your browser so! Please note that due to the large number of revocations happening in the wake of Heartbleed, revocation checks will surely increase connection delays. Plus, strictness will likely cause some connections to fail – perhaps intermittently. Keep in mind that this is merely a recommendation on how to improve your security in the wake of Heartbleed. And improved security often comes at the cost of convenience.
In the sections below, I describe how to enable revocation checking in the browsers I have access to. If your browser isn’t in the list below, feel free to ask, and I will do what I can to help… or feel free to submit instructions in the comments below if you’ve figured it out yourself.
Firefox (Windows or Mac)
On Mac: Preferences > Advanced > Certificates > Validation
On Windows: Options > Advanced > Certificates > Validation
Enable both options: “Use the Online Certificate Status Protocol (OCSP)…”, and “When an OCSP Server connection fails, treat the certificate as invalid”
Note the Firefox is the only browser of the “big three” that has a simple checkbox to enforce strictness (a hard fail).
Internet Explorer 11
Internet Options > Advanced
Under Security, there are 2 settings:
- Check for publisher’s certificate revocation
- Check for server certificate revocation
Unfortunately, to control strictness with IE you must use a registry hack, which is not something I recommend for most users. You’re welcome to read about it here
though, towards the end of the post (above the comments).
Google Chrome (Windows or Mac)
Settings > Show advanced settings…
Under the HTTPS/SSL section, enable “Check for server certificate revocation”
Most unfortunately, Google Chrome does not support any form of strictness (hard fail). It does use an offline list called a CRL, however Google has to keep that list short for performance reasons, so a hard fail mechanism would still be preferable. I know many people aren’t going to like this comment (I, myself, do not), however like my comment regarding mobile browsers above, it might be best to avoid using Google Chrome for the next little bit.