
Chrome users oblivious to Heartbleed revocation tsunami - wasd123
http://news.netcraft.com/archives/2014/04/18/chrome-users-oblivious-to-heartbleed-revocation-tsunami.html
======
tptacek
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.

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

~~~
thefreeman
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
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?

~~~
this_user
Same goes for Chromium 34.0.1847.116 on Arch.

------
nialo
The standard explanation for this is
[https://www.imperialviolet.org/2012/02/05/crlsets.html](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.

~~~
claudius
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.

~~~
tptacek
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.

~~~
claudius
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?

~~~
tptacek
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.

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

~~~
wutbrodo
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
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.

~~~
tptacek
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:

[https://news.ycombinator.com/item?id=7562185](https://news.ycombinator.com/item?id=7562185)

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

~~~
chc
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.

~~~
cauterize
Akamai scale > Cloudflare scale.

~~~
chc
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.

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

------
middleclick
Why is this not the default option?

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

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

~~~
chris_wot
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

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

~~~
jrockway
I like the one there that calls him a crackpot in 2006 for accusing the NSA of
spying by exploiting Windows bugs.

[http://attrition.org/errata/charlatan/steve_gibson/gibson_wm...](http://attrition.org/errata/charlatan/steve_gibson/gibson_wmf_backdoor.html)

~~~
tptacek
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.

~~~
jrockway
It "might"? Does it or doesn't it?

~~~
tptacek
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.

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

~~~
tptacek
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
Why are we not using DNS for this?

~~~
tptacek
Using DNS for what? CAs? Are you asking "why don't we take the crappy PKI we
have right now and just _give_ it to the world's governments"?

------
rriue
Please use original title.

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

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

~~~
tptacek
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](https://bugzilla.mozilla.org/show_bug.cgi?id=643907)

