

Google to strip Chrome of standard SSL revocation checking - JeremyBanks
http://arstechnica.com/business/guides/2012/02/google-strips-chrome-of-ssl-revocation-checking.ars

======
sgentle
I had a long comment about security of old browser versions that I just
deleted because I misread the article.

By "Chrome will instead rely on its automatic update mechanism" it means there
will be a separate update stream using the same system, not that revocation
list updates will be packaged with new Chrome versions. The latter would mean
that not upgrading Chrome would stop you from getting cert revocation updates,
which would be a Bad Thing.

To quote the original blog post[1]:

"Our current method of revoking certificates in response to major incidents is
to push a software update. Microsoft, Opera and Firefox also push software
updates for serious incidents rather than rely on online revocation checks.
But our software updates require that users restart their browser before they
take effect, so we would like a lighter weight method of revoking
certificates.

"So Chrome will start to reuse its existing update mechanism to maintain a
list of revoked certificates, as first proposed to the CA/Browser Forum by
Chris Bailey and Kirk Hall of AffirmTrust last April. This list can take
effect without having to restart the browser."

[1] <http://www.imperialviolet.org/2012/02/05/crlsets.html>

~~~
redthrowaway
>it means there will be a separate update stream using the same system, not
that revocation list updates will be packaged with new Chrome versions. The
latter would mean that not upgrading Chrome would stop you from getting cert
revocation updates, which would be a Bad Thing.

Well sure, you'd get the cert revocation updates, but you wouldn't get
security fixes, which seems equally Bad. Why wouldn't you just let Chrome do
what Chrome does? What would you gain by actively borking its update process?

~~~
sgentle
Not equally bad at all. Holding back Chrome versions means you need to keep
track of Chrome vulnerabilities to stay safe. Holding back Chrome updates and
cert revocation updates means your security surface area includes every SSL
website you use.

There are plenty of good reasons to "bork its update process", for example if
you work in enterprise and have a change management process for browser
updates. Or if Chrome introduced a feature you don't like (like Lion
fullscreen). Or if you prefer to use your OS's package management system for
browser updates.

It's not so much a matter of Chrome's update process as your update process.
If that's "I want the newest version as soon as it comes out, all the time",
then great, but there's no guarantee that's true. That's the exact reason
Firefox is doing its whole ESR thing.

~~~
mukyu
Just because enterprises have silly rules about updating software does not
make it a 'good reason'. Just think of how much effort has been wasted over
the years by most of the internet propping up IE6 to appease corporations that
have these policies.

------
jwegan
Slightly off topic, but it really bugs me that Chrome has security researchers
busy analyzing hypothetical attacks, but refuses to do anything to prevent
practical real world attacks. My 5 year old cousin can find out all my saved
passwords if given 10 seconds to access my laptop while I go to the bathroom
by going to preferences->personal stuff->managed saved passwords->and clicking
show when hovering over an obscured password.

Firefox and IE, have had the ability to require a master password to reveal
saved passwords in the password manager for years. Sure it isn't secure
against a sophisticated attacker, but at least 99% of the world's population
probably couldn't figure out how to break it, much less my 5 year old cousin.

~~~
lloeki
On OSX Chrome relies on the system Keychain so it's protected against that
case. I don't know if it can be made to use the Gnome Keyring (or its KDE
counterpart). Out of curiosity does anything like those keychains (I mean a
theoretically secure storage area for authentication tokens available to
developers and manageable by users) exists on Windows systems?

~~~
acdha
Windows has had a secure storage system for a long time
(<http://msdn.microsoft.com/en-us/library/ms995355>) but, unsurprisingly, many
developers chose not to use it and there were limited tools for interacting
with it in the base install.

------
noibl
This sounds very similar to the way Chrome handles Google's own malware-
servers list:

    
    
      "If you have phishing and malware protection enabled, then Google Chrome will 
       contact servers at Google within five minutes of startup, and approximately 
       every half hour thereafter, to download updated lists of suspected phishing 
       and malware websites"[1]
    

It would be pretty cool if they made an aggregated CRL available via the same
Safe Browsing API (used by Safari and Firefox).[2]

[1] [http://blog.chromium.org/2008/11/understanding-phishing-
and-...](http://blog.chromium.org/2008/11/understanding-phishing-and-
malware.html)

[2] <http://code.google.com/apis/safebrowsing/>

------
__alexs
From the original blog post.

> We have to be mindful of size, but the vast majority of revocations happen
> for purely administrative reasons and can be excluded.

What could possibly go wrong here?

This isn't a security improvement, it's a performance optimisation at the
expense of security for Chrome users.

> An attacker can still block updates, but they have to be able to maintain
> the block constantly, from the time of revocation, to prevent the update.
> This is much harder than blocking an online revocation check, where the
> attacker only has to block the checks during the attack.

OK sure. Except what's the actual correlation between time-of-detection and
time-of-attack in the real world? If certificates aren't getting added to CRLs
until they are actually being used in attacks then at the moment, (which
previous responses from Google to CA hacks have suggested is in fact the case)
then this optimization has bought you what? One-time use of the cert? (When
attacking Chrome users.) What's new there?

I'm not going to deny the possibility that most CA's revocation infrastructure
is so incredibly awful that this all ends up actually being a good thing for
security. CA's seem to have unbounded abilities to screw up after all. This
really doesn't seem like a direction we should be encouraging browser SSL to
go in general though.

~~~
agl
> It's a performance optimisation at the expense of security for Chrome users.

I'm arguing that the current, soft-fail revocation checking is useless and
that we're not losing anything by switching it off. The actual revocation
mechanism at the moment is that a CA highlights a major problem and all
browsers push a software update to block it, because nobody trusts the
revocation system to work.

So an update mechanism that allows us to react faster is a clear improvement
on pushing full-browser updates. But, independent of that, the soft-fail
checks aren't actually protecting anyone and it's past time that we recognised
that and prompted the introduction of schemes that actually can work, i.e.
mandatory OCSP stapling or short-lived certs.

------
gst
This problem has already been solved:
<http://en.wikipedia.org/wiki/OCSP_stapling>

Yes, there are problems with OCSP stapling, but it is much better then what's
currently used. In addition, it does not depend on a central authority as in
the approach proposed by Google.

~~~
marshray
There are two problems with OCSP stapling:

* It requires some configuration on the server side. So it probably won't be enabled for the great majority of sites until some future generation of upgrades enables it by default.

* If a MitM presents his evil server to the client, he's just going to opt out of sending the stapled OCSP response. So the browser's back in exactly the same situation where he has to block for 1 whole extra second to do traditional OCSP (and has the same hard decision to make about what to tell the user if it fails).

EDIT: Which is not to say that I don't think it's still a great idea. It just
would have worked a lot better if it had been the original OCSP mechanism.

------
drblue
Edit: Maybe wrong? see reply.

If I'm reading the sample implementation[0] correctly, the update mechanism
isn't Omaha[1] (aka Google Update), but the CRX extension update mechanism[2]
that keeps extensions and app bundles up to date.

[0]: <https://github.com/agl/crlset-tools/blob/master/crlset.go> [1]:
<http://code.google.com/p/omaha/> [2]:
<http://code.google.com/chrome/extensions/autoupdate.html>

~~~
groby_b
Uh, [0] explicitly refers to Omaha all over the place?

See e.g. this comment: // update and the related structures are used for
parsing the XML response from Omaha. The response looks like:

------
obtu
OCSP was supposed to block fraudulent certificates (as long as the break-in is
noticed and published); because of softfails the protocol fails at this task.

Google's security researchers are proposing an incrementally deployed, admin-
friendly way to prevent fraudulent certificates: Certificate transparency.
Part of it is a public log of what certificates were issued, so that site ops
notice when a certificate is issued which they didn't ask for.

Details: <http://www.links.org/?p=1212>

------
sargun
I'm glad that this change was made. We run a site that's 100% SSL. Our
internal latency testing has led us to believe that certain users are feeling
10-15% page responses because of OCSP response times.

------
verelo
Very cool, good to see this space progressing!

