Chrome to stop using online checks to spot revoked certificates

Future versions of Google’s Chrome browser will no longer use online revocation checks to verify whether the HTTPS site the user wants to visit possesses a valid certificate, shared Google researcher Adam Langley in a blog post.

So far, Crome – as, indeed, all other major browsers – sends OCSP and CRL queries to the services run by the Certificate Authorities in order to verify whether that particular certificate has been revoked. But, as Langley points out, the process is deeply flawed and Google has finally decided to do something about it.

“The problem with these checks, that we call online revocation checks, is that the browser can’t be sure that it can reach the CA’s servers,” he explains. “There are lots of cases where it’s not possible: captive portals are one. A captive portal frequently requires you to sign in on an HTTPS site, but blocks traffic to all other sites, including the CA’s OCSP servers.”

“If browsers were to insist on talking to the CA before accepting a certificate, all these cases would stop working. There’s also the concern that the CA may experience downtime and it’s bad engineering practice to build in single points of failure. Therefore online revocation checks which result in a network error are effectively ignored (this is called ‘soft-fail’).”

And, unfortunately, attackers who are able to intercept HTTPS connection can also make it so that the revocation checks appear to have failed instead of pointing out that a certificate is no longer valid, and the user is allowed to proceed to the site.

“While the benefits of online revocation checking are hard to find, the costs are clear: online revocation checks are slow and compromise privacy. The median time for a successful OCSP check is ~300ms and the mean is nearly a second. This delays page loading and discourages sites from using HTTPS. They are also a privacy concern because the CA learns the IP address of users and which sites they’re visiting,” wrote Langley and compared soft-fail revocation checks to a seat-belt that snaps when you crash.

Instead of this essentially flawed process, Chrome will use its own update mechanism to maintain a list of revoked certificates, and that will not require a restart of the browser.

“An attacker can still block updates, but they have to be able to maintain the block constantly, from the time of revocation, to prevent the update. This is much harder than blocking an online revocation check, where the attacker only has to block the checks during the attack,” he points out, and invited CAs to contribute their revoked certificates to the list.