No More SSL Revocation Checking For Chrome

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

Comments

Why?

[John Hasler]

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

Re:Why?

[Spad]

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.

Re:Why?

[Richard_at_work]

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.

Re:Why?

[Imagix]

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.

Re:Why?

[vlm]

The solution is more resilient servers and services, not eliminating the checking.

Such as, say, having the Mighty GOOG distribute that "CRL in all but name". Which brings us full circle back to the original article, and what they're doing.

Re:Why?

[kbg]

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

Re:Why?

[kbg]

Yes it should. CRL server for X is mission critical and should always work. There is no excuse for it not working.

Re:Why?

[Anonymous Coward]

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.

Re:Why?

[Guppy06]

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

Re:Why?

[Hentes]

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.

Re:Why?

[Joce640k]

At the very least don't display the padlock icon as if everything is cool.

(Also, keep retrying the certificate request to see if it succeeds. Change the padlock color when it does).

Re:Why?

[icebraining]

That's not the only way to get a compromised certificate.

Remember that any CA can create a certificate for any domain. So It might be that some attacker got hold of an intermediate CA certificate and issued a certificate for the bank's domain. Now, the CA detects the breach and revokes the intermediate certificate, but since Chrome fails to check them, it still gets accepted.

You have a full MITM scenario without any fault from the bank or the bank's CA.

Re:Why?

[icebraining]

Twitter as an example of reliability? Are you joking? You do know where the expression "fail whale" came from, right?

Re:Why?

[Guppy06]

When was the last time you so much as looked out a window when you heard a car alarm?

Great idea.

[Targen]

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

And the solution, obviously, is not checking at all. Slick.

Re:He's right

[xorsyst]

Opera didn't have to distribute a patch, because they use OCSP and CRLs properly. And I've never heard of anyone complaining that it causes a problem.

Re:Being Google

[Ferzerp]

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.

Re:Being Google

[swillden]

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.

Google is already the authority which decides which CAs will be trusted by Chrome. How does it really change anything if Google also collects the CA CRLs and pushes them to the browser? Other than making revocations much more reliable.