One of the consequences of the drama around the OpenSSL heartbleed vulnerability is that security experts have begun taking a hard look again at the certificate revocation process and whether it actually protects users or gives them any visibility into the validity of a given certificate. In a lot of cases, the answer is probably no.
A key mechanism in the certificate authority system is the ability of CAs to revoke certificates. This is necessary for a number of reasons, many of which have to do with a certificate being stolen or compromised in some way. That’s one of the worries with the heartbleed vulnerability, because a successful attack on a vulnerable server could allow the attacker to steal the secret key associated with the server’s certificate. With that key, the attacker could impersonate the vulnerable site.
So sites that were running vulnerable OpenSSL installations have been breaking the relationship between their certificate and their old public key and getting a new public key. But, as security researcher Adam Langley of Google points out, the old certificates still work, so the attacker with the old private key could still use the certificate. Browsers for years have had a mechanism built in that allows them to check to see whether a specific certificate is still valid. If it’s been revoked, the browser receives a signal and the user will get a warning about the certificate being invalid.
The protocol this process uses is OCSP (online certificate status protocol), which will give the browser a signed assertion that tells the browser whether the certificate is still good. But if the browser doesn’t get a response from the OCSP server, the browser has to decide whether to accept the certificate in question or reject it. Langley said that virtually everyone defaults to accepting all certificates, for a few reasons, but that it’s essentially a useless choice. He gives the example of an attacker who is able to intercept all of a victim’s traffic.
“If you’re worried about an attacker using a revoked certificate then the attacker first must be able to intercept your traffic to the site in question. (If they can’t even intercept the traffic then you didn’t need any authentication to protect it from them in the first place.) Most of the time, such an attacker is near you. For example, they might be running a fake WiFi access point, or maybe they’re at an ISP. In these cases the important fact is that the attacker can intercept all your traffic, including OCSP traffic. Thus they can block OCSP lookups and soft-fail behaviour means that a revoked certificate will be accepted,” Langley wrote in an essay encouraging users to disable certificate revocation checking in their browsers.
There are a number of other attack scenarios Langley outlines, including a nation-state attacker who can intercept all of a victim’s traffic or a lower-level attacker who can only intercept specific portions of it.
“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,” Langley wrote.
There a lot of considerations that go into the decision by a browser vendor or user to implement or enable the certificate revocation check, and it’s not a simple binary choice, said Robert Hansen, director of product management at WhiteHat Security, and a long-time security researcher.
“The major reason the browsers turned it off is because of performance. The CAs can’t be relied upon to run their own OCSP servers,” Hansen said. “Let’s say everyone turns it on, the problem from one perspective is that it will totally break some things, like the denial-of-service attacks on OCSP servers. But which do you think is worse? It depends on your perspective. Would you rather be denied service or be man-in-the-middled?”
Google Chrome doesn’t use CRL (certificate revocation lists) as the default mechanism for checking the status of certificates, unlike most other browsers. Instead, Google employs a tactic that monitors the status of certificates on high-value sites, and pushes daily updates to Chrome users. So if a certificate for a prominent site is revoked, Chrome users, via the automatic update feature, will get that information within a day or so.
“It’s called the CRLSet and it’s not complete, nor big enough to cope with large numbers of revocations, but it allows us to react quickly to situations like Diginotar and ANSSI. It’s certainly not perfect, but it’s more than many other browsers do,” Langley wrote.
“A powerful attacker may be able to block a user from receiving CRLSet updates if they can intercept all of that user’s traffic for long periods of time. But that’s a pretty fundamental limit; we can only respond to any Chrome issue, including security bugs, by pushing updates.”
Hansen said that, as in many cases, the CAs themselves end up being part of the problem.
“It should be a prerequisite that a CA be able to have an OCSP server up one hundred percent of time. It should be as reliable as DNS,” he said.
