No More SSL Revocation Checking For Chrome

← Back to Stories (view on slashdot.org)

No More SSL Revocation Checking For Chrome

Posted by timothy on Tuesday February 7, 2012 @04:35AM from the substitute-my-own dept.

New submitter mwehle writes with this bit from Ars Technica: "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."

18 of 152 comments (clear)

Min score:

Reason:

Sort:

Why? by John+Hasler · 2012-02-07 04:37 · Score: 4, Insightful

...Chrome and most other browsers establish the connection even when the services aren't able to ensure a certificate hasn't been tampered with.
Why?

--
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
1. Re:Why? by Spad · 2012-02-07 04:42 · Score: 4, Insightful
  
  Because otherwise (as I've discovered by switching it on in Seamonkey) about 20% of the time the connection to the CRL/OCSP server fails for whatever reason and so your site won't load, even though there's nothing wrong with its certificate.
  Now you might argue that false positives are preferable to ignoring problems, but it does break the user experience pretty badly.
2. Re:Why? by Richard_at_work · 2012-02-07 04:49 · Score: 5, Insightful
  
  Yes. Because if you are in a MITM position to inject your own compromised cert for site Y, then you are also in the perfect position to deny access to the cert validation servers to stop the validation happening.
  The solution is more resilient servers and services, not eliminating the checking.
3. Re:Why? by Imagix · 2012-02-07 04:53 · Score: 4, Insightful
  
  Now you might argue that false positives are preferable to ignoring problems, but it does break the user experience pretty badly.
  And this is the problem with security. People want the security/safety.... unless it's inconvenient. And yes, there is something "wrong" with the certificate. It is unverifiable as to whether it is still valid. Which you asked it to do.
4. Re:Why? by Baloroth · 2012-02-07 04:57 · Score: 5, Informative
  
  Hint: should every site with an SSL cert from X not work because X is unreachable for whatever reason right this second?
  Yes. Anyone conducting a MITM attack is practically necessarily in control of the users network, and will just block access to the CRL, which means they will never stop MITM attacks unless you do exactly that. And yes, I know that is the point of the change. My point is: they choose the wrong fix. Sites should only be listed as trusted if the browser really knows they can be (so far as possible, of course). Being "Secure" should meet a minimum standard, and failing that standard means the site should not be listed as "secure", but most browsers do. Choosing to simply ignore part of the established SSL standard is not the solution.
  Opera does precisely this. It still used HTTPS (I think), but it doesn't list the page as being secure, since the page really has exactly the same security as any non-https site (for trust purposes).
  
  --
  "None can love freedom heartily, but good men; the rest love not freedom, but license." --John Milton
5. Re:Why? by kbg · 2012-02-07 04:58 · Score: 5, Insightful
  
  "CRL/OCSP server fails for whatever reason".
  No it fails because the server administrators for the CRL are incompetent morons. A CRL server is a mission critical server that should stay up 24-7.
  If Chrome and other browsers would simply display an error page with text explaining the problem and point to the offending server, I am sure the problems would be fixed very quick.
6. Re:Why? by kbg · 2012-02-07 05:03 · Score: 4, Insightful
  
  Yes it should. CRL server for X is mission critical and should always work. There is no excuse for it not working.
7. Re:Why? by Anonymous Coward · 2012-02-07 05:11 · Score: 5, Insightful
  
  If a CA cannot keep their uptime, they shouldn't be in the business. Part of the fairly high cost of certificate purchases is the fact the CA is going to run multiple, geographically distributed data centers with adequate server coverage. That, or hire a provider that has is ready/willing/able to do this.
  It is just like banks -- if a bank's server failed causing a loss of transaction info for a period of time, nobody would care how hard it is to have 99.999% uptime -- the bank failed in its duties regardless of the reason (hardware failure, Internet issues, security issues, etc.) This is just the same with CAs and revocation.
8. Re:Why? by Guppy06 · 2012-02-07 05:17 · Score: 5, Insightful
  
  The real problem with false positives isn't that they are "inconvenient" but that they breed complacency. If 99% of the alerts you get are false, what are the odds you'll actually give enough due diligence to catch the remaining 1%?
9. Re:Why? by Hentes · 2012-02-07 05:31 · Score: 5, Insightful
  
  They could load the site and simultaneously display a small warning, thus letting the users decide whether they want to trust it or not. Loading an untrusted is not a tragedy by itself.
10. Re:Why? by Anonymous Coward · 2012-02-07 06:31 · Score: 4, Funny
  
  And that explains why when my car is read-ended, it's always completely undamaged.
  The magic of liability protects me.
  True story.
Re:What? by Kohenkatz · 2012-02-07 04:51 · Score: 4, Informative

What he wants is CRLs stored on the local machine instead of querying a web service.
Re:What? by vlm · 2012-02-07 04:53 · Score: 4, Informative

So basically he wants CRLs? I thought he didn't want CRLs?
Not want CRLs distributed from sites no one cares about.
CRLs fail unlocked, so to speak. So if you can't pull a CRL from a CA the browser goes on its merry way. So if you're pulling a MITM attack using a known compromised cert, "everyone knows" you just block access to the CA. End users will never notice. 99.9999% of end users will never visit anything with a *.verisign.com domain.
However, if you block access to www.google.com or plus.google.com or gmail.com because they're distributing a meta-CRL THEN "most" users will notice the might GOOG is dead.
So you start with a web of trust where no one cares if any of the threads are cut. Thats not gonna work. So how bout piggybacking the web of trust on top of a Very Popular Site. Being a GOOG guy (I think?) he suggests his employer, although I know of no technical reason why itunes.apple.com or microsoft.com couldn't also distribute CRLs.
Now if you want to pull a MITM attack its not enough to null route the CAs, you can't null route the Mighty GOOG without the users noticing, so you have to do something much more sophisticated to block access to the most recent CRL.
The funny part is now all the noobs who report internet outages as "google is down" are going to have to wonder, is someone trying to pull a MITM or is it just noob-speak for an internet outage...

--
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Re:Being Google by Spad · 2012-02-07 04:53 · Score: 4, Informative

All they're really doing is moving the certificate revocation checks from the client to the server; Google updates its own CRL and pushes it to Chrome so that the browser doesn't have to rely on potentially unresponsive 3rd party sites for its checks.
He's right by HBI · 2012-02-07 05:03 · Score: 4, Informative

CRLs and OCSP are functionally useless. For PKI to work, certificate revocation must work also. Some kind of reliable system has to be constructed. Chrome is doing what they need to do to make this happen by abandoning the useless, outdated technologies of the past.
Before someone asserts otherwise, explain DigiNotar. While you are at it, explain all the rest of the CA compromises over the last two years. Then explain why each browser essentially had to distribute a patch to fix the problem rather than relying on OCSP and CRLs. If they are functional, that wouldn't have been necessary.

--
HBI's Law: Frequency of calling others Nazis is directly correlated with the likelihood of the accuser being Communist.
Yeah decades. by Anonymous Coward · 2012-02-07 05:27 · Score: 4, Informative

X509 certificates go back to July 3, 1988.
That makes certificates (and their revocation) 24 years old.
So yes, decades old.
Re:Being Google by Ferzerp · 2012-02-07 05:44 · Score: 4, Insightful

Except now Google is presenting itself as an authority on the status of certificates that it has no business doing so with to the users of chrome.
This is a bad thing.
False warnings by Firethorn · 2012-02-07 06:27 · Score: 5, Interesting

I harp on this constantly. At work, we fairly routinely issue people new certificates and revoke the old ones, even when there's no belief that the certs were compromised. As a result, you can send somebody an email and later that day get new certs. This is a problem because all the digitally signed emails you sent earlier now register as revoked and Outlook proceeds to tell you this, that the email can't be trusted, etc...
This happens frequently enough that I encounter this 2-3 times a week. The email has always been valid, they just got new certs between their sending the messages and my opening the email(possibly for historical reasons).
Same deal as with the california cancer warning - stick it on EVERYTHING, and it gets ignored. If you put cancer warnings on apples, they may not pay attention to the cancer warning on that bottle of test chemical.

--
I don't read AC A human right