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." In fairness to Google a test performed after this article was published showed Chrome blacklisted the TLS certificate Ars revoked three weeks ago. The text of the article as it originally ran 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.
Further HowReading Heartbleed transformed HTTPS security into the stuff of absurdist theaterCertificate revocation checking in browsers is "useless," crypto guru warns.
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.
Further HowReading Heartbleed transformed HTTPS security into the stuff of absurdist theaterCertificate revocation checking in browsers is "useless," crypto guru warns.
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.
RSS Feed