No More SSL Revocation Checking For Chrome 152
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."
Re:What? (Score:5, Informative)
Re:What? (Score:5, 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...
Re:Being Google (Score:5, 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.
Re:Why? (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).
Comment removed (Score:5, Informative)
Yeah decades. (Score:4, Informative)
X509 certificates go back to July 3, 1988.
That makes certificates (and their revocation) 24 years old.
So yes, decades old.