Chrome users oblivious to Heartbleed revocation tsunami

http://news.netcraft.com/archives/2014/04/18/chrome-users-oblivious-to-heartbleed-revocation-tsunami.html

by wasd123 • 12 years ago

116 59 12 years ago

news.netcraft.com

facorreia• 12 years ago

Trading security for performance seems to be a recurring issue among many projects.

wutbrodo• 12 years ago

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.

AnthonyMouse• 12 years ago

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.

tptacek11• 12 years ago

This isn't an exchange of security for performance. It's an exchange of theater for reliability.

papaf• 12 years ago

Why is checking for certificate revocations theater? It seems sensible to me.

Edit: I mean downloading a revocation list rather than checking online.

higherpurpose• 12 years ago

I've enabled mine since Steve Gibson said we should do it 2 weeks ago on Security Now.

chris_wot• 12 years ago

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.

How good is his security advise?

jlgaddis• 12 years ago

  http://attrition.org/errata/charlatan/steve_gibson/

cauterize2• 12 years ago

Was there a reason Cloudflare was singled out? Akamai is doing the same mass-revocation of certs as well.

chc2• 12 years ago

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.

cauterize2• 12 years ago

Akamai scale > Cloudflare scale.

crucialfelix3• 12 years ago

Checking: "Check for server certificate revocation" does not persist. When I check it and then reopen the settings tab it is again unchecked.

Does anybody else see this ?

Chrome Version 34.0.1847.116

I've reported it twice now.

Roritharr• 12 years ago

Doesn't happen to me on Windows 8.1 Chrome Version 34.0.1847.116 m

thefreeman• 12 years ago

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.

edit: 34.0.1847.116 m

tombrossman• 12 years ago

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?

xux• 12 years ago

Using 34.0.1847.120

It's checked by default, just looked.

ryanpardieck• 12 years ago

It's persistent for me.

I'm on 36.0.1941.0 dev-m.

chaosmonkey• 12 years ago

35.0.1916.27 beta

The check is persistent.

seacious• 12 years ago

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.

[1] https://productforums.google.com/forum/#!topic/chrome/npSTSO...

crucialfelix3• 12 years ago

Maybe we have an extension that is causing this. I'll try disabling them tomorrow and see if the UI works.

xtc• 12 years ago

Does not happen to me. Windows 7 x64, same version number. Perhaps it's an issue with sync?

Atroxide2• 12 years ago

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.

lowmagnet• 12 years ago

Mine's still ticked after setting it last week.

Same version you've got, on mac.

ballpoint• 12 years ago

Same here.

manish_gill• 12 years ago

Yep. Check still working on same version for OS X.

crucialfelix3• 12 years ago

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.

middleclick• 12 years ago

Why is this not the default option?

Atroxide2• 12 years ago

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."

erso• 12 years ago

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.

bigbugbag• 12 years ago

trade-off for performance against other browsers.

nialo• 12 years ago

The standard explanation for this is https://www.imperialviolet.org/2012/02/05/crlsets.html

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.

claudius2• 12 years ago

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.

lomnakkus2• 12 years ago

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".

rdl• 12 years ago

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?)

tptacek11• 12 years ago

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.

rriue• 12 years ago

Please use original title.

Also see previous discussion about this decision: https://news.ycombinator.com/item?id=7557149

mkr-hn• 12 years ago

Glad I read HN. Why isn't this checked by default?

tptacek11• 12 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.

takeda• 12 years ago

Why are we not using DNS for this?

lnanek2• 12 years ago

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. ;/

tptacek11• 12 years ago

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:

https://bugzilla.mozilla.org/show_bug.cgi?id=643907

pekk• 12 years ago

What a sensationalist title. The real title is "Chrome users oblivious to Heartbleed revocation tsunami" which makes much more sense.

tptacek11• 12 years ago

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.

Chrome users oblivious to Heartbleed revocation tsunami

Related Stories