In the wake of the critical Heartbleed vulnerability, many security experts are advising that site owners regenerate the keys used for their site’s SSL certificate, create a new certificate using the fresh keys, and revoke their old certificate. Of course, that’s exactly what site owners should do, but there’s a quirk in the way modern browsers handle SSL certs that could potentially reduce the effectiveness of certificate revocations.
An SSL certificate, in simplified terms, ties together a public key pair and a domain name. The private component of the key pair is a secret known only to the site. If that private key becomes known to a third party, then it’s no longer possible to guarantee that data encrypted using that key or a site verifying its identity with that key is really what it appears to be.
The Heartbleed bug potentially exposed hundreds of thousands of private keys, and so site owners are advised to change their key and generate new certificates. Clearly that’s not much use if browsers consider the old certificate to be as valid as the new, so they must be revoked. While it’s easy enough to revoke certificates, in many circumstances, browsers don’t do revocation checking — they don’t look to see whether a certificate has been revoked. That means even if certificates have been revoked, there’s a chance that browsers will consider them valid.
This seems like an obvious security vulnerability, but there’s valid reasoning behind it. If browser developers were strict about revocation checking, it would likely “break the Internet” for large numbers of users.
Revocation checking uses a protocol called OCSP to check whether certificates have been revoked. But OCSP isn’t always available: sometimes OCSP servers can’t be checked. If browser developers adopted a hard-fail policy and rejected all certificates when they were unable to check their revocation status, the Internet would cease to work properly in various circumstances. There would be a single point of failure for all sites using SSL, which could be easily exploited by hackers to bring sites down. Instead, the only reasonable approach is to adopt a soft-fail approach, only rejecting certificates when browsers have positive evidence of revocation.
The problem with the soft-fail approach is that it’s not much use: if an attacker is in a position to exploit SSL encrypted data, they can probably also block OCSP packets, meaning that revoked certs will always be accepted because no positive verification of revocation status is possible.
On top of that, OCSP creates extra latency for SSL connections and sends certificate authorities comprehensive information about which sites a user has visited, creating privacy issues. All of which means that most browsers don’t bother with having revocation checking turned on by default.
Google Chrome has an alternative revocation checking facility called CRLSets, whereby Certificate Revocation Lists are pushed to the browser as part of its update process. Unfortunately, CRLSets are not comprehensive and, especially in the case of a mass certificate revocation, can’t be relied on to have all certificate revocations — the list would be enormous.
It is possible to turn on revocation checking in modern browsers; they can all do it, but it’s not active by default. Activating it can potentially degrade the experience of browser users, and the chances of actually being hit by a man-in-the-middle attack are pretty slim. On top of which, soft-fail revocation checking doesn’t do much to protect users anyway.
Does this mean that sites shouldn’t bother revoking their old certificates? Absolutely not. Revoking a certificate doesn’t guarantee that it will never be accepted, but using new keys will help protect users going forward.
Image: Flickr/Dennis Wong