First, this is (was) an editorialized title, and of the worst sort: written to pre-seed a partisan angle into the thread.
Second, it's especially amusing to see people try to find reasons to dig into Google over Heartbleed, given that Google found and rapidly published Heartbleed; other providers talked about speculative countermeasures for Heartbleed as potential "competitive advantages".
Finally, the post is wrong. It correctly explains that Chrome uses CRLsets for high-profile sites instead of full CRL checks or OCSP, but incorrectly attributes the reasoning to performance. That, as it turns out, is not the reason for Chrome handling revocation the way it does. The real issue is that revocation doesn't really work: browsers (at best) "soft-fail" revocation (when Google's Adam Langley built a revocation-stripping proxy, he found for instance that IE reacted to it merely by removing the EV indicator from the URL bar), because hard-failures cause serious reliability problems.
The Netcraft article certainly is written to convey the notion that Chrome is cavalier about TLS security. But people who follow TLS know that to be a ludicrous narrative, in the truest sense; worthy of ridicule. The reality is that the Chromium team has apparently thought more carefully about revocation than almost anyone else, came to an important and counterintuitive conclusion about it, and made the design decision that maximized user safety given the constraints.
Wow, you are right. I was chuckling to myself looking at this article thinking Good thing I am smart and enabled this check. Then I read your comment, checked my settings and indeed the setting is no longer enabled.
I understand that the CRL isn't fool proof, but if your connection isn't in a position to be MITM'd it still provides protection against some things, for example if the target website DNS has been hijacked.
Maybe with news of Heartbleed a chrome update happened which forces chrome to check for revocations? Might just be a UI issue with showing it as an option and could be always on. Is there any way to test if it does indeed do the check?
Most likely not though. in the Dev branch its fixed and I was able to turn it on.
The short version is that any attacker against whom certificate revocation might matter is by definition in a position to MITM connections, and can simply interrupt the certificate check.
And the correct interpretation of ‘interrupted revocation check’ is ‘invalid certificate’. Now, of course there’s the problem that the CAs are apparently unable to provide constantly-running OCSP servers, making such an interruption more likely to be due to technical inadequacy of the CA than due to an ongoing MITM attack, but that is first and foremost a problem of the CAs, not of a browser vendor.
There's no platonic ideal of Security that exists in a vacuum, unaffected by the economic/convenience/performance/etc costs. The clearest example here is post-9/11 security, but this trade-off exists in EVERY security system, far from being an "issue" with certain projects. As far as I'm aware, this is considered a pretty fundamental tenet of security in a pedagogical context. Now of course there's still room to disagree with the level to which each project sets its security/cost-avoidance slider, but it's hardly black-and-white.
I don't see how bringing that up would have added anything to the article. He probably mentioned Cloudflare because they had done the most PR around the incident.
The article states "However, most Google Chrome users are left in the dark, as Chrome performs neither type of check for non-EV certificates by default. Instead of conventional revocation checks, Google Chrome relies on an aggregated list of revocations, dubbed CRLSets, which are compiled by Google. The revocations from GlobalSign's CRL have not yet appeared in Google's CRLSets and hence Chrome users will not be warned if presented with a potentially compromised, but revoked, CloudFlare certificate.
The CRLSets deliberately do not cover all CRLs in an attempt to reduce the total size of the aggregated list. In effect, Google has traded the completeness of their revocation checking for a speed advantage over rival browsers as downloading CRLs or making OCSP requests imposes a performance penalty."
It was at some point in the past. I recently booted up an old machine of mine that's running Chrome 7.0.517.41 beta, and the option is both there and ticked by default.
I've got mixed feelings about Steve Gibson. He's clearly very, very smart. But he does tend to be a little overdramatic, and I recall him railing against raw sockets in Windows XP a number of years ago.
Because it doesn't work; it's a double bind: either you hard-fail on revocation checks, in which case users can lose connectivity if they happen to not have connectivity to the CA (as in the captive portal case, or with broken proxy/cache servers), or you allow the user to connect anyways, in which case attackers can simply override the revocation check.
It also involves you telling a CA which sites you're visiting.
Pretty funny. Chrome has always claimed to be more secure because it makes it a pain in the ass to browse sites with expired certs - something almost always just site error. But not they've messed up in a very visible revocation case and are least secure. :)
Too bad it didn't break CloudFlare. I really hate that service. Several web sites I use, if they give me an error from a form or such, CloudFlare will just give me a cached page and I have no clue what was wrong because I can't read the actual HTTP response sent to me. ;/
They haven't messed up. They've thought more about the revocation issue than almost anyone else on the Internet, and come to the conclusion that the costs aren't worth the benefits. They appear to be right; SSL revocation is a debacle, and, for most browser configurations, is mere theater.
Here's a starting point for understanding how under-designed online revocation is for SSL/TLS:
[+] [-] tptacek|12 years ago|reply
Second, it's especially amusing to see people try to find reasons to dig into Google over Heartbleed, given that Google found and rapidly published Heartbleed; other providers talked about speculative countermeasures for Heartbleed as potential "competitive advantages".
Finally, the post is wrong. It correctly explains that Chrome uses CRLsets for high-profile sites instead of full CRL checks or OCSP, but incorrectly attributes the reasoning to performance. That, as it turns out, is not the reason for Chrome handling revocation the way it does. The real issue is that revocation doesn't really work: browsers (at best) "soft-fail" revocation (when Google's Adam Langley built a revocation-stripping proxy, he found for instance that IE reacted to it merely by removing the EV indicator from the URL bar), because hard-failures cause serious reliability problems.
The Netcraft article certainly is written to convey the notion that Chrome is cavalier about TLS security. But people who follow TLS know that to be a ludicrous narrative, in the truest sense; worthy of ridicule. The reality is that the Chromium team has apparently thought more carefully about revocation than almost anyone else, came to an important and counterintuitive conclusion about it, and made the design decision that maximized user safety given the constraints.
[+] [-] crucialfelix|12 years ago|reply
Does anybody else see this ?
Chrome Version 34.0.1847.116
I've reported it twice now.
[+] [-] thefreeman|12 years ago|reply
I understand that the CRL isn't fool proof, but if your connection isn't in a position to be MITM'd it still provides protection against some things, for example if the target website DNS has been hijacked.
edit: 34.0.1847.116 m
[+] [-] lowmagnet|12 years ago|reply
Same version you've got, on mac.
[+] [-] Atroxide|12 years ago|reply
Most likely not though. in the Dev branch its fixed and I was able to turn it on.
[+] [-] xtc|12 years ago|reply
[+] [-] Roritharr|12 years ago|reply
[+] [-] nialo|12 years ago|reply
The short version is that any attacker against whom certificate revocation might matter is by definition in a position to MITM connections, and can simply interrupt the certificate check.
[+] [-] claudius|12 years ago|reply
[+] [-] facorreia|12 years ago|reply
[+] [-] wutbrodo|12 years ago|reply
[+] [-] tptacek|12 years ago|reply
[+] [-] cauterize|12 years ago|reply
[+] [-] chc|12 years ago|reply
[+] [-] pekk|12 years ago|reply
[+] [-] middleclick|12 years ago|reply
[+] [-] Atroxide|12 years ago|reply
The CRLSets deliberately do not cover all CRLs in an attempt to reduce the total size of the aggregated list. In effect, Google has traded the completeness of their revocation checking for a speed advantage over rival browsers as downloading CRLs or making OCSP requests imposes a performance penalty."
[+] [-] erso|12 years ago|reply
[+] [-] bigbugbag|12 years ago|reply
[+] [-] higherpurpose|12 years ago|reply
[+] [-] chris_wot|12 years ago|reply
How good is his security advise?
[+] [-] mkr-hn|12 years ago|reply
[+] [-] tptacek|12 years ago|reply
It also involves you telling a CA which sites you're visiting.
[+] [-] rriue|12 years ago|reply
Also see previous discussion about this decision: https://news.ycombinator.com/item?id=7557149
[+] [-] lnanek2|12 years ago|reply
Too bad it didn't break CloudFlare. I really hate that service. Several web sites I use, if they give me an error from a form or such, CloudFlare will just give me a cached page and I have no clue what was wrong because I can't read the actual HTTP response sent to me. ;/
[+] [-] tptacek|12 years ago|reply
Here's a starting point for understanding how under-designed online revocation is for SSL/TLS:
https://bugzilla.mozilla.org/show_bug.cgi?id=643907
[+] [-] unknown|12 years ago|reply
[deleted]