How Heartbleed transformed HTTPS security into the stuff of absurdist theater

If you want to protect yourself against the 500,000 or so HTTPS certificates that may have been compromised by the catastrophic Heartbleed bug, don't count on the revocation mechanism built-in to your browser. It doesn't do what its creators designed it to do, and switching it on makes you no more secure than leaving it off, one of the Internet's most respected cryptography engineers said over the weekend.

For years, people have characterized the ineffectiveness of the online certificate status protocol (OCSP) as Exhibit A in the case that the Internet's secure sockets layer and transport layer security (TLS) protocols are hopelessly broken. Until now, no one paid much attention. The disclosure two weeks ago of the so-called Heartbleed bug in the widely-used OpenSSL cryptography library has since transformed the critical shortcoming into a major problem, the stuff of absurdist theater. Security experts admonish administrators of all previously vulnerable websites to revoke and reissue TLS certificates, even as they warn that revocation checks in browsers do little to make end users safer and could indeed weaken the security and reliability of the Internet if they were made more effective.

Certificate revocation is the process of a browser or other application performing an online lookup to confirm that a TLS certificate hasn't been revoked. The futility of certificate revocation was most recently discussed in a blog post published Saturday by Adam Langley, an engineer who was writing on his own behalf but who also handles important cryptography and security issues at Google. In the post, Langley recites a litany of technical considerations that have long prevented real-time online certificate revocations from thwarting attackers armed with compromised certificates, even when the digital credentials have been recalled. Some of the considerations include:

• Attacks that use compromised or fraudulently issued TLS certificates more often than not are premised on the hacker's ability to intercept traffic passing between the target and the open Internet. This capability means attackers can use a mechanism known as OCSP stapling to retransmit a previous response signed by the OCSP server showing a certificate is valid, even though the real OCSP server, if the victim could reach it, would report it as revoked.
• Even in cases of domain name system hijacking and other hacks that allow attackers to intercept only traffic from a specific site, attackers can often cache thwart OCSP by saving a valid response issued earlier for the targeted website and presenting it along with a compromised certificate. What's more, if attackers have hijacked a website, there's a good chance they can use that control to trick a recognized certificate authority into issuing a TLS certificate for it.
• Most crucially, virtually all websites and browser makers prefer certificate revocations to work with what security engineers call a soft error, or "soft fail", rather than a "hard fail." A soft fail permits an HTTPS connection to be established even if the OCSP server isn't currently available to confirm a certificate's validity, whereas a hard fail would reject the connection. The reason for the soft fail default is that the Internet isn't reliable enough to guarantee OCSP servers are always available. If end users visiting PayPal, Amazon, or countless other websites get hung up waiting for OCSP checks, frustration on an unprecedented scale would almost certainly ensue. What's more, switching to a hard fail mechanism would give miscreants waging denial of service attacks a potent new weapon for taking down huge swaths of the Internet. Rather than overwhelm the sites themselves, the attackers would only need to target the much smaller pool of OCSP servers that validate the sites' certificates.

"That's why I claim that revocation checking is useless—because it doesn't stop attacks," Langley wrote. "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."

Langley's blog post helps explain why Google Chrome by default doesn't have online revocation enabled. In the aftermath of Heartbleed, many people have counseled turning it on. That's because the OpenSSL bug allows attackers to pluck passwords, authentication cookies, and even private encryption keys out of the computer memory of vulnerable servers. In many cases, there is no way to know if the two-year-old flaw has been exploited. As a result, security experts have counseled people administering vulnerable websites to assume the key bound to their old TLS certificate is compromised. That has meant getting a new certificate and revoking the old one.

Online certificate checking is the mechanism many have assumed would prevent end users from trusting revoked credentials. Certificate revocation by sites remains a good idea, but in light of this weekend's post, end users shouldn't assume OCSP will do much to flag old compromised keys that may be presented by attackers.

Langley said as an alternative to online revocation checking, Chrome developers instead compile daily lists of revocation for high-value sites and deliver the certificate revocation list to end users as a normal browser update. This CRLSet, as it's called at Google, is useful for containing damage resulting from hacks such as the 2011 compromise of Dutch certificate authority Diginotar, which allowed attackers to mint fraudulent TLS credentials for Google and a relatively small number of other high-value sites. Alas, CRLSet will do little or nothing to protect users against the huge number of certificates potentially compromised by Heartbleed. Web services firm Netcraft estimates the figure could affect as many as 500,000 certificates.

The Heartbleed debacle is by no means the first event to underscore the inadequacy of current TLS revocation. A variety of researchers have proposed alternatives. One such fix, devised by cryptography experts Moxie Marlinspike and Trevor Perrin, is known as TACK. Another one was created by a developer from Red Hat and is dubbed Mutually Endorsing CA Infrastructure. Langley, meanwhile, held out something called OCSP Must Staple.

Those proposals and several others like them have largely languished in inertia. If there's a silver lining to Heartbleed, it may be that it provides the catalyst that the huge number of the world's engineers will need to finally fix one of the Internet's biggest security holes.

Post updated to add detail about OCSP stapling in the fourth paragraph.