Report: Browser is "blind" to 98 percent of potentially compromised certificates.

Update: A few hours after this article went live, Google engineer Adam Langley published a blog post taking issue with the GRC characterization that Chrome's CRLSet is "completely broken." In the post, Langley said he has always been clear that the measure isn't perfect, but in any event, it's more effective than the revocation checks on by default in other browsers. "And yet, GRC managed to write pages (including cartoons!) exposing the fact that it doesn't cover many revocations and attacking Chrome for it." The text of the article follows:

The ability of Google Chrome to block secure website connections compromised by the Heartbleed bug is "completely broken" because the browser by default detects less than three percent of the underlying digital certificates that have been revoked, according to a detailed analysis recently posted online.

The charge was leveled against CRLSet, a regularly updated list in Chrome that catalogs website encryption certificates that have been revoked recently. Last week, noted cryptography engineer and Google employee Adam Langley promoted CRLSet as an improvement over the online certificate status protocol turned on by default in most other browsers. Langley blasted OCSP as "useless" because he said it was trivial to bypass and threatened to harm the performance and stability of the overall Internet.
Analysts at Gibson Research Corporation (GRC) have now shot back with data they say shows that Chrome's CRLSet fails to flag hundreds of thousands of transport layer security (TLS) and secure sockets layer certificates revoked in response to the catastrophic Heartbleed bug that afflicted the OpenSSL crypto library for two years. Overall, CRLSet blocks just 24,259 revoked certificates, less than three percent of all unexpired certificates that have been formally recalled as untrustworthy by their issuers. What's more, the special Chrome list blocks TLS credentials issued by just 53 certificate authorities (CAs) out of the 353 CAs trusted in Microsoft Windows and the 211 CAs trusted by Mac OS X.

"We know that Chrome's CRLSet includes at most 2% of the revoked certificates currently published by the Internet's certificate authorities," a post GRC researchers last updated Monday stated. "Chrome will blindly trust the remaining 98% of the Internet's revoked and not-yet-expired certificates. And, of course, new revocations are being published every day, 98% of which Chrome will never be aware of."

Among the potentially compromised certificates trusted by Chrome, 140,000 of them alone belonged to content delivery network CloudFlare, which had them revoked in the days following the disclosure of Heartbleed. It's unknown exactly how many other certificates were revoked in response to Heartbleed, but given the number of issuers that are ignored by CRLSet, the amount could easily be hundreds of thousands more.

Officials with CloudFlare declined to comment. Google representatives didn't respond to an e-mail seeking comment for this article. The GRC results were based on a Chrome version available on April 23. It's possible the contents of the browser's CRLSet have been updated since then.

Security theater redux

The GRC analysts went on to note at least two examples of Chrome incorporating the revocation of two benign certificates following highly public notices that they were no longer valid but were still being trusted by the Google browser. One was a long-revoked certificate for https://revoked.grc.com/, and the other corresponded to cloudflarechallenge.com, a site CloudFlare created to test how easily private keys could by stolen when attackers exploit Heartbleed-susceptible servers. Remarkably, both of the recalled certificates were subsequently blocked by adding their cryptographic signing keys to the CRLSet file header, a highly unusual location that suggests more of an on-the-fly kluge than a standard or methodical undertaking by Google developers.

"We know that the appearance of the entirely benign revoked.grc.com test, and news that the certificate for the cloudflarechallennge.com website had been revoked, threatened to reveal that Chrome would not automatically block those revoked certificates," the GRC analysts wrote. "We know that when they need embarrassing certificates to be blocked, they make special cases of them, adding them manually, as static entries, into the header of Chrome's CRLSet, because that's the only thing that works. Thus, by any reasonable definition of "broken"... We know that Chrome's CRLSet certificate revocation system is completely broken. It cannot, and should not, be relied upon to protect the security interests of its users."

The analysis is troubling because TLS certificates are the sole means that millions of websites use to cryptographically prove their servers are authentic and to encrypt user traffic so it can't be monitored or tampered with by eavesdroppers. Site operators rely on revocation to invalidate certificates that may be compromised when their private keys become known publicly. The entire system becomes moot if revoked certificates remain trusted by browsers because attackers can continue to use them in man-in-the-middle attacks.

Mozilla's Firefox browser, by contrast, automatically blocked the revoked.grc.com certificate several days before Chrome's developers added a manual override, the blog post said. The addition of the benign sites is significant because some users relied on the findings they generated to conclude Chrome was much more effective than was really the case at blocking certificates that had been revoked in response to Heartbleed. Ironically, the move by Google came as the Langley post suggested OCSP was "security theater" because of the "absurdly specific situation in order for it to be useful."

Running out of time

The barbs traded between Langley and the GRC researchers provide yet more evidence of the almost complete dysfunction of the Web's current TLS system. Langley makes a convincing case that almost anyone in a position to exploit a site's compromised TLS certificate can also bypass the certificate revocation checks carried out by default with most non-Chrome browsers. The GRC analysis, in turn, demonstrates that Chrome's CRLSet alternative provides no meaningful improvement over that sad state affairs.

As Ars has laid out in previous coverage, there are a variety of proposals that aim to shore up the flagging TLS system. Heartbleed graphically demonstrates that we're running out of time. If Internet architects don't act soon, things will get much, much worse.

Updated to sentence about lack of comment from CloudFlare and Google, details about the effective date of the CRLSet contents in the sixth paragraph; "by default" in the first paragraph.

Hmm , good idea Google