14 DAY TRIAL // Adam Langley, Google engineer working on the HTTPS infrastructure and Chrome’s network, is slamming GRC over research saying that Chrome is not efficient in fighting off Heartbleed after it characterized the CRLSet as “completely broken.”
Langley said that he hadn’t hidden the fact that things weren’t perfect, but even so, the method chosen by Google was more effective than the revocation checks set on by default in other browsers. “It’s certainly not perfect, but it’s more than many other browsers do,” he says.
“The original CRLSets announcement contained two points. Firstly that online revocation checking doesn't work and that we were switching it off in Chrome in most cases. Secondly, that we would be using CRLSets to avoid having to do full binary updates in order to respond to emergency incidents,” Langley explains.
He explains that Google compiles daily lists of high value revocations and uses Chrome’s auto-update mechanism to push them to all users. CRLSet is not complete, nor big enough to cope with large numbers of revocations, but it allows the company to quickly react in critical situations.
Revocations are divided into important and administrative, and Google was hoping to push the important ones first, since the administrative ones occur only when a certificate is changed with no reason to suspect that any key compromise occurred.
“And yet, GRC managed to write pages (including cartoons!) exposing the fact that it doesn't cover many revocations and attacking Chrome for it. They also claim that soft-fail revocation checking is effective. The claim is that a user will download and cache a CRL while not being attacked and then be protected from a local attacker using a certificate that was included on that CRL. (I'm paraphrasing; you can search for ‘A typical Internet user’ in their article for the original),” Langley writes.
Basically, he believes that CRL is the best option to handle the entire post-Heartbleed situation. The alternative, OCSP, only covers a single certificate and is used in preference to CRL because it’s much smaller than it. Furthermore, OCSP removes the need to download the larger CRLs.
His blog post gets really technical, but the bottom line is that Google stands by the solution it picked to handle the onslaught of security certificates since any alternative would just put a strain on the bandwidth required and the resources of the client.
Since mobile devices are also at risk here, Google really doesn’t see any other way to go about this.