Ministry of Innovation —

Google to strip Chrome of SSL revocation checking

Comparing online revocation checking to seat belts that snap when you crash, a …

Google's Chrome browser will stop relying on a decades-old method for ensuring secure sockets layer certificates are valid after one of the company's top engineers compared it to seat belts that break when they are needed most.

The browser will stop querying CRL, or certificate revocation lists, and databases that rely on OCSP, or online certificate status protocol, Google researcher Adam Langley said in a blog post published on Sunday. He said the services, which browsers are supposed to query before trusting a credential for an SSL-protected address, don't make end users safer because Chrome and most other browsers establish the connection even when the services aren't able to ensure a certificate hasn't been tampered with.

"So soft-fail revocation checks are like a seat-belt that snaps when you crash," Langley wrote. "Even though it works 99% of the time, it's worthless because it only works when you don't need it."

SSL critics have long complained that the revocation checks are mostly useless. Attackers who have the ability to spoof the websites and certificates of Gmail and other trusted websites typically have the ability to replace warnings that the credential is no longer valid with a response that says the server is temporarily down. Indeed, Moxie Marlinspike's SSL Strip hacking tool automatically supplies such messages, effectively bypassing the measure.

"While the benefits of online revocation checking are hard to find, the costs are clear: online revocation checks are slow and compromise privacy," Langley added. That's because the checks add a median time of 300 milliseconds and a mean of almost 1 second to page loads, making many websites reluctant to use SSL. Marlinspike and others have also complained that the services allow certificate authorities to compile logs of user IP addresses and the sites they visit over time.

Chrome will instead rely on its automatic update mechanism to maintain a list of certificates that have been revoked for security reasons. Langley called on certificate authorities to provide a list of revoked certificates that Google bots can automatically fetch. The time frame for the Chrome changes to go into effect are "on the order of months," a Google spokesman said.

109 Reader Comments

This is nuts. The solution is to make CRL/OCSP failure a hard error, not silently ignore it.

"But what if PayPal's CRL/OSCP server goes down?" is the response. Well, what if it does? You won't be able to be MITM attacked when using PayPal. This is not bad, just as it's not bad that you can't format your hard disk when you're not an Administrator.

CRL activity is perhaps the only reason that we even know about some of the Comodo hacks that occurred last year. There was a spike in the number of requests made by Iranian machines to a rather obscure Dutch CA, which lets us gauge the full extent of the disruption that Iranians suffered at the hands of their government (and/or an independent Iranian nationalist). I think this kind of activity is important.

I believe also that Comodo updated its CRL before the browser vendors rolled out patches to their browsers.

And Google wants to do this to give its browser the appearance of being 300 milliseconds faster? Insane.

The article does not make this clear but I assume the replacement will be a hard fail instead of the mandated soft fail. Presumably Google thinks that its infrastructure is faster and more reliable than the others so they can reduce the 300ms delays.

Langley called on certificate authorities to provide a list of revoked certificates that Google bots can automatically fetch.

I hope that he meant Google bots, and Microsoft bots, and Mozilla bots, and Apple bots, and - well, the world at large. Regardless, this just seems like a bad idea. If methods and policies are broken, fix them - don't encourage every concerned party to fend for themselves, invent their own solutions, or just turn it all off out of frustration with the state of standards and practices.

The article does not make this clear but I assume the replacement will be a hard fail instead of the mandated soft fail. Presumably Google thinks that its infrastructure is faster and more reliable than the others so they can reduce the 300ms delays.

TFA wrote:

Chrome will instead rely on its automatic update mechanism to maintain a list of certificates that have been revoked for security reasons. Langley called on certificate authorities to provide a list of revoked certificates that Google bots can automatically fetch.

His valid concern is that the revocation lists can be blocked during an attack, mitigating most of their utility. Instead, he suggests:

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

Now attacks would have to block chrome update 100% of the time to allow the same behaviour as a soft fail, instead of just during the attack.

The only viable alternative to a local revocation list, that I can think of, would be a distributed/redundant one... where the attacker would to have many remote phoney lists maintained, and the browser samples a random subset of them. But that is probably ugly, or at least slow.

Langley called on certificate authorities to provide a list of revoked certificates that Google bots can automatically fetch.

I hope that he meant Google bots, and Microsoft bots, and Mozilla bots, and Apple bots, and - well, the world at large.

The article meant "can automatically fetch" in the most literal sense that, in order to participate, a CRL has to be fetchable by GoogleBot. If you read the linked blog post you'll see that basically means that it's available via HTTP and "robots.txt must not exclude GoogleBot".

Quote:

Regardless, this just seems like a bad idea. If methods and policies are broken, fix them - don't encourage every concerned party to fend for themselves, invent their own solutions, or just turn it all off out of frustration with the state of standards and practices.

This *is* a solution. It's suggesting to make standard what is already happening today: browsers are not relying on revocation checking, they are revoking certificates by shipping updates.

Adam Langley isn't some guy just making shit up as he goes along here (knee-jerkers should note this apparently didn't even originate with Google, but on a CA mailing list). The current system is seriously broken. This might not be the best solution, but that's why "on the order of months" is a good thing.

CRL's should just be TXT records in DNS. We have DNSSEC so we can authenticate the lists validity, DNS is known to be massively scalable, and with DNSSEC it's pretty damn hard to tamper with the records without being noticed. I guess you could overload the DNS server of issuing authority to block responses but that would be a pretty noticeable action and the client could treat lookup failures as bad certificates since a non-working DNS stack shouldn't be expected on any working computer.

Ironically, the certificate revocation system reduces privacy, as Langley points out. Every time you contact a server over SSL, you also contact the revocation server, which can aggregate some of your browsing history. The more you use SSL to improve security, the more your privacy is potentially violated. Langley certainly didn't miss the opportunity to sell this as a privacy win for Chrome and Google.

Actually this is nothing. SSL and CA stuff is basically broken. The CRL system is just the worst bit, it's not only useless, but it also makes using SSL painful, particularly on high latency connections.

Wow, I'm honestly a bit amazed at the pure amount of stupidity in the comments so far. Google not only makes SSL _more secure_ but also _increases your privacy_ all by just accepting and using _standard-proprosed practices_ and they're the Bad Guys because of it?

I particularly like the idiotic response about putting CRLs in DNS TXT records. Clearly you people aren't applying even 4 seconds of thought to what you're typing.

Wow, I'm honestly a bit amazed at the pure amount of stupidity in the comments so far. Google not only makes SSL _more secure_ but also _increases your privacy_ all by just accepting and using _standard-proprosed practices_ and they're the Bad Guys because of it?

I particularly like the idiotic response about putting CRLs in DNS TXT records. Clearly you people aren't applying even 4 seconds of thought to what you're typing.

How does increasing the latency between a certificate being revoked and the client getting notified increase security? As to the CRL's in DNS comment, you can already do this in an MS AD configuration because the records are secured, now that we have DNSSEC we should be able to do it on a larger scale. Next time try defeating the argument rather than attacking the poster, it'll give you more credebility.

Wow, I'm honestly a bit amazed at the pure amount of stupidity in the comments so far. Google not only makes SSL _more secure_ but also _increases your privacy_ all by just accepting and using _standard-proprosed practices_ and they're the Bad Guys because of it?

Yep, Google (and Mozilla) already ship certificate blacklists (including CA certificates!), this is just saying that CRL are totally useless (because they are) and coming up with a solution that's an all around win. And, nobody is saying that it can't coexist with any other solutions. This will be by far the easiest change, that doesn't risk crippling massive number of websites with a CA's half-assed CRL server goes down (i.e. if you go to hard fail), or depend on the CA to do their job (which they've been doing an increasingly bad job of!)

I'm not sure exactly how the protocols CRL servers use works, but, if they migrate to hard fail I'd imagine the various tools would switch over to impersonating the server instead (which might raise the bar a bit, but unlikely too much).

And, going distributed wouldn't help too much either in the case of Iran/a bottleneck, since they often can intercept any arbitrary traffic going out (either directly, or via poisoning the route to go through them), so whether they need to impersonate one server or a dozen wouldn't make a huge difference (software is good at repetitive tasks!).

elanthis wrote:

I particularly like the idiotic response about putting CRLs in DNS TXT records. Clearly you people aren't applying even 4 seconds of thought to what you're typing.

Yeah, that doesn't seem exactly like it would work, since, you know, DNSSEC still doesn't enjoy massive deployments... and would be putting it at the wrong place, anyways! Not to mention various other miscellaneous issues with the idea ranging from practicality to technical.

Wow, I'm honestly a bit amazed at the pure amount of stupidity in the comments so far. Google not only makes SSL _more secure_ but also _increases your privacy_ all by just accepting and using _standard-proprosed practices_ and they're the Bad Guys because of it?

I particularly like the idiotic response about putting CRLs in DNS TXT records. Clearly you people aren't applying even 4 seconds of thought to what you're typing.

And your post is so much better?CRLs are meant to be long term revocation lists of known bad servers, OCSP is meant to be the immediate update mechanism for breaches that occurred in the last day or so. So how is Google's solution a replacement for that? They are basically ditching the OCSP protocol and replacing it with CRLs and block lists (but they already had CRLs/block lists anyway).OCSP is soft fail because (yet again) the Trusted Certificate Authorities are not doing their job. They make money selling Certs and by charging triple for ones that make your browser bar go green to indicate they have done the checks they should have done for all certs anyway. OCSP servers are just overheads to them so they are often under-resourced and too busy to respond so browsers soft fail.The correct response is for all browsers vendors to group together and say from June 1st all OCSP responses will be hard fail and then set up a big PR campaign so that all server operators/users will know when their traffic drops from certificate errors who to blame, and sue. Hit them in the wallet (like DigiNotair) it's the only time they listen.

Wow, I'm honestly a bit amazed at the pure amount of stupidity in the comments so far. Google not only makes SSL _more secure_ but also _increases your privacy_ all by just accepting and using _standard-proprosed practices_ and they're the Bad Guys because of it?

More secure? How is delaying the CRL update until the next browser update (or whatever) "more secure" than fetching the latest CRL or hitting the OCSP server and getting a bang up-to-date indication of whether the certificate has been revoked?

"But you can block the CRL!" is not an answer. Make CRL retrieval a hard failure!

Wow, I'm honestly a bit amazed at the pure amount of stupidity in the comments so far. Google not only makes SSL _more secure_ but also _increases your privacy_ all by just accepting and using _standard-proprosed practices_ and they're the Bad Guys because of it?

I particularly like the idiotic response about putting CRLs in DNS TXT records. Clearly you people aren't applying even 4 seconds of thought to what you're typing.

How does increasing the latency between a certificate being revoked and the client getting notified increase security? .

It will not. All browser vendors do this already e.g. Microsoft has contracts in place as part of their certificate program (as I imagine everyone else does) to oblige the Trusted Certificate Authorities to notify them immediately. It's pure Google PR fluff: "We want to make our browser look faster so we are ditching this broken system. But its OK we're Google with search bots and things so err profit?"

afidel wrote:

As to the CRL's in DNS comment, you can already do this in an MS AD configuration because the records are secured, now that we have DNSSEC we should be able to do it on a larger scale. Next time try defeating the argument rather than attacking the poster, it'll give you more credebility.

True but nobody deploys it at the moment. So maybe this will work in a few years but it is not a solution now.

Wow, I'm honestly a bit amazed at the pure amount of stupidity in the comments so far. Google not only makes SSL _more secure_ but also _increases your privacy_ all by just accepting and using _standard-proprosed practices_ and they're the Bad Guys because of it?

More secure? How is delaying the CRL update until the next browser update (or whatever) "more secure" than fetching the latest CRL or hitting the OCSP server and getting a bang up-to-date indication of whether the certificate has been revoked?

"But you can block the CRL!" is not an answer. Make CRL retrieval a hard failure!

They will not do this at the moment as people will complain that Chrome will not connect to their web sites but IE or whatever will. So as much as browser vendors claim to care about our security they care more about their own image. Note: I'm not picking on Goolge here everyone else hasn't done this for the same reason.

We need an upfront industry wide push for hard failure together with information so everyone knows who is at fault when failures happen so Certificate Authorities will have to provision more servers or loose their customers. Until this happens the CA will not up their game...

They will not do this at the moment as people will complain that Chrome will not connect to their web sites but IE or whatever will. So as much as browser vendors claim to care about our security they care more about their own image. Note: I'm not picking on Goolge here everyone else hasn't done this for the same reason.

We need an upfront industry wide push for hard failure together with information so everyone knows who is at fault when failures happen so Certificate Authorities will have to provision more servers or loose their customers. Until this happens the CA will not up their game...

Then work with the other vendors to get checking turned on by default, and to make failure to verify revocation a hard error. If all the browsers do it together, no-one is disadvantaged. Everyone knows that soft errors render the system pointless.

There's just no way that checking a live, up-to-date, current revocation list could be worse than checking a stale one. Google's decision is in no sense a step forward.

And they should implement TLS 1.1 and 1.2, while they're at it. Whining that OpenSSL or NSS (or whatever library it is that they depend on) doesn't support it so they can't doesn't cut the mustard. They're a multibillion dollar corporation, they can write some patches.

They will not do this at the moment as people will complain that Chrome will not connect to their web sites but IE or whatever will. So as much as browser vendors claim to care about our security they care more about their own image. Note: I'm not picking on Goolge here everyone else hasn't done this for the same reason.

We need an upfront industry wide push for hard failure together with information so everyone knows who is at fault when failures happen so Certificate Authorities will have to provision more servers or loose their customers. Until this happens the CA will not up their game...

Then work with the other vendors to get checking turned on by default, and to make failure to verify revocation a hard error. If all the browsers do it together, no-one is disadvantaged. Everyone knows that soft errors render the system pointless.

There's just no way that checking a live, up-to-date, current revocation list could be worse than checking a stale one. Google's decision is in no sense a step forward.

Your solution is unfortunately mostly for imaginary town. It's like advocating "just turn on IPv6" a few years ago. It will, as you know, break many many things, it doesn't solve the fundamental problems with CAs anyway, and it's likely to instead encourage the non-use of SSL and people circumventing the limited protections that browsers do offer. Most CAs are not built for that kind of high availability (if they're not actually unstaffed) and all it takes is a major CA going down for a day to cause large sections of the internet not to work. Every business from Google down to the one man startup would become completely dependent on not only their CA's trustworthiness but their infrastructure as well (let alone their ability to weather an Anonymous DDoS attack) And you still don't solve the latency problem.

One popular suggested fix (while staying within the design of the current system) would be instead to have certificates that expired every few days. That allows enough flexibility to have the same strictness but allow large bouts of latency in the CA system. That wouldn't be "in no sense a step forward", it would be a large improvement over the situation today. And...that's roughly equivalent to this solution. It's not perfect (we need to move on from the CA system), but it is a large improvement and it's something that can actually be done.

CRL's should just be TXT records in DNS. We have DNSSEC so we can authenticate the lists validity, DNS is known to be massively scalable, and with DNSSEC it's pretty damn hard to tamper with the records without being noticed. I guess you could overload the DNS server of issuing authority to block responses but that would be a pretty noticeable action and the client could treat lookup failures as bad certificates since a non-working DNS stack shouldn't be expected on any working computer.

In relation to the problem at hand, though, the main issue is that it can easily take 2 to 3 days to propagate DNS changes, giving you roughly what is proposed here. In any case, I'm personally more partial to other distributed trust/notary systems than using DNS for this.

Wow, I'm honestly a bit amazed at the pure amount of stupidity in the comments so far. Google not only makes SSL _more secure_ but also _increases your privacy_ all by just accepting and using _standard-proprosed practices_ and they're the Bad Guys because of it?

More secure? How is delaying the CRL update until the next browser update (or whatever) "more secure" than fetching the latest CRL or hitting the OCSP server and getting a bang up-to-date indication of whether the certificate has been revoked?

"But you can block the CRL!" is not an answer. Make CRL retrieval a hard failure!

That would be a DoS nightmare... you would never be able to make it a hard failure without exposing yourself to this threat. No one will ever do that... and that is why its mostly a useless check.

Ironically, the certificate revocation system reduces privacy, as Langley points out. Every time you contact a server over SSL, you also contact the revocation server, which can aggregate some of your browsing history. The more you use SSL to improve security, the more your privacy is potentially violated. Langley certainly didn't miss the opportunity to sell this as a privacy win for Chrome and Google.

That is bullshit. The CRL file itself is signed (and timestamped) and can easily be downloaded (and cached) via annonimizer proxy without any risk to security.

The only issue I see is that for the CRL to be effective, the browser needs to stop treating it as an optional check (as PeterB pointed out) and start implementing SSL fully. Unfortunately (for us) this goes against the interest of browser makers since it makes establishing a secure connection to a server slower and depending on two different servers (the actual server and the CRL/OCSP server).

Don't fool yourself: that isn't a move made to improve your security. The failure path that is described in the article isn't even what CRL is supposed to protect you against.

That would be a DoS nightmare... you would never be able to make it a hard failure without exposing yourself to this threat. No one will ever do that... and that is why its mostly a useless check.

How so ? The CRL/OCSP check is much more lightweight than the actual SSL connection. Sure, it has two points of failure instead of one (although this can be mitigated by providing several CRL distribution points in the certificate). And you cannot have it both way: if you want to be sure that your connection is secure, you HAVE to validate it and you HAVE to interrupt it in case of failure instead of just assuming it's nothing.

Google's argument really should have been "Sure, crash belts are effective but nobody uses them so, instead of sounding a loud and annoying warning when it's not locked, we'll just remove it from our cars." It's not making anything safer, it's just making it cheaper for Google.

They will not do this at the moment as people will complain that Chrome will not connect to their web sites but IE or whatever will. So as much as browser vendors claim to care about our security they care more about their own image. Note: I'm not picking on Goolge here everyone else hasn't done this for the same reason.

We need an upfront industry wide push for hard failure together with information so everyone knows who is at fault when failures happen so Certificate Authorities will have to provision more servers or loose their customers. Until this happens the CA will not up their game...

Then work with the other vendors to get checking turned on by default, and to make failure to verify revocation a hard error. If all the browsers do it together, no-one is disadvantaged. Everyone knows that soft errors render the system pointless.

There's just no way that checking a live, up-to-date, current revocation list could be worse than checking a stale one. Google's decision is in no sense a step forward.

Your solution is unfortunately mostly for imaginary town. It's like advocating "just turn on IPv6" a few years ago. It will, as you know, break many many things, it doesn't solve the fundamental problems with CAs anyway, and it's likely to instead encourage the non-use of SSL and people circumventing the limited protections that browsers do offer. Most CAs are not built for that kind of high availability (if they're not actually unstaffed) and all it takes is a major CA going down for a day to cause large sections of the internet not to work. Every business from Google down to the one man startup would become completely dependent on not only their CA's trustworthiness but their infrastructure as well (let alone their ability to weather an Anonymous DDoS attack) And you still don't solve the latency problem.

Bull. OCSP stapling deals with all the issues you discuss. It lets the server download and cache the most current signed OCSP response to send with its certificate. So the client never needs to contact the the certificate issuer. Of course nobody does this now because there is little incentive to. Soft failures "fix" so many problems.

In any case are you really reconmending that we use unstaffed low availability CAs?

This is nuts. The solution is to make CRL/OCSP failure a hard error, not silently ignore it... And Google wants to do this to give its browser the appearance of being 300 milliseconds faster? Insane.

Agreed. What is stopping Google from re-engineering Chrome so that it provisionally DISPLAYS the site (while blocking data-entry e.g. of passwords) and then retrospectively blocks the site with a hard failure and warning message if CRL fails? This would fix the 300ms - 1s delay AND the security at the same time.

"But what if PayPal's CRL/OSCP server goes down?" is the response. Well, what if it does? You won't be able to be MITM attacked when using PayPal. This is not bad, just as it's not bad that you can't format your hard disk when you're not an Administrator.

Just to clarify: you won't be able to access the "secure" parts of PayPal at all. Yes, this does mean you won't be susceptible to an MITM attack, but it's more like not being able to log in at all than not being able to format the hard drive.

Personally, I think this would be acceptable behaviour. The fact that browser makers don't already do it is, in my opinion, symptomatic of a dangerous mind-set amongst browser makers: the mind-set that rendering the content is the absolute top priority, regardless of how it's accomplished and what shortcuts are taken. For years, browsers have been rendering invalid HTML, hiding error messages (in some cases, hiding the very fact that an error has occurred), putting notifications and warnings inside the content area instead of in dedicated UI widgets, failing to distinguish between errors from proxies and errors from origin servers, and so on. If we ever want to be truly secure, we need to inform the user of exactly what is going on with their connections and content, in clear, unambiguous ways. Make it obvious when an error has occurred, make the nature of the failure clear (transient? security-related? network conditions? error returned from a proxy?) using UI elements not easily spoofed by phishers and other attackers, and give users the option of displaying the actual error text returned from upstream, if available.

Why anyone ever trusted the worlds largest *advertising* firm to do the right thing is just remarkable.

What's that got to do with anything? Yes, they advertise. So?

The company is in advertising...and searching...and emailing...and office productivity...and dozens (if not hundreds) of other services. What company doesn't offer multiple service lines or products?

Do you really believe there is a company out there...online or off...that doesn't track it's customers and use/sell that data? Do think that Ford doesn't know it's buyers' demographics? Do you think Publix doesn't track your purchases? Do you think Old Navy doesn't know where you live and when your birthday is?

The problem here is that waiting until a certificate gets revoked and then adding it to Google's list is like calling the cops after a crime has been committed...it's reactive instead of proactive.

I agree with the hard fail option. We need more security on the net, not less. I will be happy to endure an additional second or two of load time if it means adding security to credit card purchases or viewing bank statements.

If people aren't getting through to a website because the company's certificate is invalid or expired, or because their server is down, then that's the company's problem, not Google's.

Don't compromise the integrity of the web for all of us because a couple of companies can't maintain their own servers.

The biggest problem is that the CAs are not stepping up. Microsoft created their own CRL years ago because Verisign had a CRL but did not list its location (CDP) so no browser could get to it. Wow, that's helpful!

We have a very large DMVPN network where all traffic, everywhere, is encrypted using certificates. CRL absolutely does work. It was as simple as making sure the CDP record was available to the endpoints - both the record itself and access to its contents - and voila, if we add something to the CRL, it takes effect nearly immediately. A little tweaking of client-side caching of CRLs and you have something that can work over the internet easily.

We need more security on the net, not less. I will be happy to endure an additional second or two of load time if it means adding security to credit card purchases or viewing bank statements.

I agree with the sentiment.But the internet doesn't work like that. Banks and other payment-related websites are not the majority of SSL users. It is unacceptable to have unscalable technology as a core part of the security the *entire internet*.You want a more secure web? So do I. I want all the websites I visit to run https. Is it gonna happen? Not as long as they take three times longer to load under https.

The way forward is more security at a lesser cost. Keeping unscalable and costly technology just because "it's slightly more secure" is not acceptable.

What is stopping Google from re-engineering Chrome so that it provisionally DISPLAYS the site (while blocking data-entry e.g. of passwords) and then retrospectively blocks the site with a hard failure and warning message if CRL fails? This would fix the 300ms - 1s delay AND the security at the same time.