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

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

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.

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.

They can push updates fast enough[0] that they don't want this to wait after a restart.

And since you're bringing software updates into this, even though an optimal strategy will target both problems independently: one can't force users to restart without a lot of pain, as long as there isn't true session checkpointing.

[0] Thialfi: http://research.google.com/pubs/archive/37474.pdf

I think it's more that they want the ability to ship a revocation as cheaply and easily possible rather than tying it to a binary release.

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.

er, that sounds exactly what you would expect from a security researcher :)

More seriously, these are certainly not hypothetical attacks (the DigiNotar thing was just a few months ago), and the fact that that "1%" can figure out how to see your passwords just by googling "master password firefox" shows exactly why this isn't a security issue (in some strict sense).

You could certainly make it slightly harder to see them than clicking a few buttons (with the same reasoning you put a confirmation dialog before someone deletes their life's work), but there are good arguments on both sides about the utility of that kind of security theater.

This doesn't work for everyone, but I personally set up a guest account on my computer and enable fast user switching. I can worry a lot less about multiple aspects of my 5 year old cousin using my computer, then.

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?

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.

Use LastPass, don't save passwords with Chrome.

Use a screen lock.

Whoa... Thank you for alerting me to that, I just deleted all my saved passwords. That's absolutely insane.

A malicious attacker with 30 seconds on your machine unobserved could just keylog you.

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

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

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.

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

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.

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.

OCSP stapling is good for privacy and latency, but it requires every server to upgrade to provide any increased security. Until then it is as insecure as OCSP: it can just be stripped.

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

Omaha is a service which we ask questions like: "I've got version $x of $foo, what should I do?". We use it for extensions as well as the main browser update.

The CRLSet is packaged as an extension (it's actually a .crx), but with a custom install callback that delta updates the current version.

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:

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

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.

Very cool, good to see this space progressing!