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.
For Chromium version 33.0.1750.152 Ubuntu 12.04, The settings change is persistent.
Related question: Is anyone seeing degraded browsing performance as a result of this change yet? It is my understanding that these CRLs are spiking in size to multiple megabytes, no?
Chromes ability to save settings silently fails with disturbing regularity (in my experience). A lot of people seem to have seen the issue (e.g. [1], and google will reveal many more) but consistent steps to reproduce seem hard to come by. It's one of the main annoyances that made me switch back to firefox.
I'm on OS X too. Possibly could be an extension messing with it. That's usually what causes behavior that not everybody else sees on the same release version.
Some above in the comments have confirmed what I saw.
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.
Congratulations, you just broke every user accessing the Internet through a captive portal with an HTTPS login interface, and every user trying to access the Internet through crappy proxies. Which is one of the reasons why other browsers don't hard-fail on revocation checks.
And what exactly is the alternative? If any intermediate proxy/captive portal can say ‘oh, everything is fine’, how are we going to protect against MITM attacks?
Out-of-band online CA checking is a weak design that doesn't work in practice. If revocation is required in a strict sense, then the solution will look something like "nuclear HSTS-style OCSP stapling". But to my mind, a simpler alternative would be for browsers to support something like TACK, so that instead of trying to knock down known-bad certificates, we just had a much better infrastructure for asserting which certificates are good.
All that aside though, it's awfully silly to kick Google for noticing and pointing out this security problem with revocation checking. Other browsers are often literally pretending to do revocation checks that aren't actually meaningful.
I wish Cloudflare or Google would get into the CA game; they'd be more than capable of doing OCSP checks on every use, and could issue very short lived certificates otherwise (weekly?)
OTOH that just leads to completely trivial DoS attacks (AFAICS, at least). Of course that's a lot better than trivial MITM, but it's still not exactly "good".
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.
There are also contexts in which the trade-off doesn't actually exist. Extraneous complexity breeds performance problems and security problems.
The horrible mess of ancient cruft that comprises the existing certificate infrastructure is a more fundamental cause of the problem here than what this or that browser does to try to mitigate the damage.
The problem isn't the certificate infrastructure; it's the protocol.
Online revocation checking could be made to work. We know the shape the solution will take. It will look like a redesigned version of OCSP stapling (where instead of connecting out to an OCSP server, the TLS server itself relays the revocation assertion over the TLS connection), but for chained certificates, and with an HSTS-like persistence mechanism so that attackers can't skip revocation checks by simply not sending the Certificate Status extension.
This is a lot of work to get certificate revocation, which is a rarely-used feature. But dynamic certificate pins are useful all the time, and solve some of the same problems as revocation. They also happen to be a persistent, cached attestation that accompanies a TLS connection.
So, perhaps the right thing to do is (wait for it) push for TACK:
Because the real world breaks OCSP checks often enough that browsers can't tell the difference between e.g. a malfunctioning proxy and an attacker; therefore, browsers don't hard-fail the checks, so attackers can slip past them. And in exchange for that theater, you're telling the CAs what sites you're visiting. It is a crazy system.
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.
I don't follow the point you're trying to make. Steve Ballmer has 70 lbs on Tim Cook, so any article that mentions Cook must mention Ballmer on account of his greater size?
The article was just about how there have been a lot of revoked certs lately and Chrome won't see them. Cloudflare just provided an easy source for the first part. Mentioning Akamai wouldn't have made any difference to the substance or the narrative.
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.
That is an extremely misleading summary of the page you linked to; to start with, Jericho is at pains not to reject the idea that the USG uses Windows bugs to spy. Your comment might say more about your credibility than his, unfortunately.
I don't know what the circumstances of your comment were. Did you just not read it very carefully, or did you deliberately misstate it?
I originally wrote that your comment did say more about your credibility (&c &c), but edited it because I realized I didn't have any business attributing motive to what might have been a totally innocent error. Sorry about that.
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:
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.