Chrome does certificate revocation better

Everyone's talking about it: The Great Certificate Revocation Storm of 2014. Because of the Heartbleed bug, a very large number of SSL/TLS web sites need to revoke and reissue their certificates.

The circumstances create the equivalent of several major Internet traffic jams. Things will be slower for everyone... except maybe Google Chrome users. They do things differently. (While we're on the subject, there are many articles out there telling users to turn on certificate revocation checking in Chrome. Don't. Bad idea. More about this below.)

Here's how SSL/TLS is supposed to work for site authentication: Browsers and other user-agents are supposed to check, when they get certificates from sites, whether those certificates have been revoked or are still valid. There are two methods for checking: Certificate Revocation Lists (CRLs), which are simple lists of serial numbers of certificates that have been revoked, provided by each Certificate Authority (CA); and a communication protocol called Online Certificate Status Protocol (OCSP), which allows a system to check with a CA for the status of a single certificate without pulling the entire CRL, which, as we'll see, can become quite large.

The other day, certificate authority CRL grew to approximately 4.7MB in size from approximately 22KB because CloudFlare, a Content Delivery Network (CDN) that uses GlobalSign as their primary CA partner, decided to revoke and reissue all their customer certificates. That was about 50,000 unique certificate revocations at once, and you can bet it's not the last such mass-change in the near-term.

Now imagine that users all over the Internet are checking for certificate revocation and having to pull a file that's many MB in size. It can be cached to a point, but we can also assume that CRLs are more volatile than they have usually been. This all adds up to the CAs turning into a major performance bottleneck on the Internet for the near future. Even OCSP can be effectively cached through a technique called OCSP stapling, in which the certificate authority includes the OCSP response with the certificates.

And in practice, it's not practical to be completely scrupulous about revocation checking. For one thing, revocation checks can fail for many different reasons and you can't treat the failure as a finding of revocation, so such failures are generally ignored by browsers; this is called a "soft fail."

The harsh, but accurate conclusion from this is that certificate revocation checking doesn't actually work. Any actor in a position to intercept your traffic (which is why they would want to decrypt it) is also in a position to cause revocation checking to fail. Since the browser will just punt when this happens, it means that revocation checking does nothing; the man in the middle can use a revoked certificate if he wants to — any browser will let him get away with it. I don't want to claim that such circumstances are likely or easy to create, but a determined actor with resources is not prevented by the technology from accomplishing them.

For this and other reasons, Google decided in 2012 to default Chrome not to check for certificate revocation on non-EV certificates. (EV or Extended Validation certificates are more expensive certificates with more stringent buyer verification and browser behavior rules.) Instead, Google uses their Chrome update mechanism to send batches of serial numbers of revoked certificates which it constantly gathers by crawling Certificate Authorities.

Google's approach trades off some precision, in that the CRLSet may be old compared to the contents of the current CRL or the response of an OCSP request, but in exchange the user gains some performance and reliability. As a Google spokesperson said to me, "...[W]hen we identify a bad cert, we update our revocation list, and Chrome users are automatically protected. CRLSet updates occur at least daily, which is significantly faster than most OCSP validity periods."

Even so, there are many, like Netcraft, who have been telling Chrome users to turn on certificate revocation checking. But Google's Adam Langley shows that this is a big mistake, for the reasons already stated, i.e., that revocation is broken:

That's why I claim that online revocation checking is useless — because it doesn't stop attacks. Turning it on does nothing but slow things down. You can tell when something is security theater because you need some absurdly specific situation in order for it to be useful.

I don't know many independent observers (independent meaning not a CA) who would defend the current revocation system. When faced with the facts of the post-Heartbleed world it looks like a poorly thought-out hack. Most of us see the hack and complain about it. Google saw the hack and did something about it. Something imperfect, but something worthwhile.

The weaknesses of the certificate revocation process aren't completely news to those who follow these matters, but now it's impossible to claim that the system works. I only wish I had seen a decent idea for something to replace it. Langley speculates about a solution involving short-lived certificates or mandatory OCSP, which effectively amounts to the same thing. But in fact, there are no solid plans out there to make a better system. In the meantime, many security claims on the Internet are exaggerated.