Slashdot Mirror
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."
Why?
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Given the painful uselessness of CRLs as presently implemented(we obviously need some way of revoking the things; but the present one is agonizingly broken), I'm just not too sad about the prospect of no longer telling Verisign every time I visit one of their SSL-cert customers(the same is true of all the other certificate mongers who publish CRLs)...
So he admits Chrome is broken, so he doesn't fix it and blames the CA's . . makes sense.
So basically he wants CRLs? I thought he didn't want CRLs?
Your hair look like poop, Bob! - Wanker.
And the solution, obviously, is not checking at all. Slick.
Once a Lulzsec type organization got your private keyz you are fucked.
It's so easy to turn the Internet into whatever you want it to be, when you're the largest advertiser, largest service provider, largest search engine, largest content provider, software maker, hardware-platform-vendor, and even an ISP.
Have we reached the point where google's "too big to fail"?
----
Not to be confused with Col.
I think Google is just trying to make the browser fast. Updating the CRL "out of band" always runs the risk of using an outdated CRL. I think they are trying to explain their decision by saying that the "in-line" check is anyways not 100% secure (so why waste precious milliseconds).
"Google's Chrome browser will stop relying on a decades-old method for ensuring secure sockets layer certificates are valid..."
'Decades'? As in more than one?
The first web browser was made by Tim Berners-Lee in 1991. That's technically two decades ago...but were there secure sockets? Layers? Certificates?
Yeah, I'm nitpicking. But the web didn't exist publically before 1994 -- I remember formatting HTML for Mosaic back then, as our company tried to keep on top of the bleeding edge. This stuff really wasn't that long ago. Correcting 'decades' is just a nitpick, but if you start using 'centuries' or 'eons' then this old man is going to have to get out of his chair and start giving history lessons.
Genocide Man -- Life is funny. Death is funnier. Mass murder can be hilarious.
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.
Google will parse CRLs on their servers and push updates to Chrome instead of having Chrome poll on demand, because on-demand polling is most likely to soft-fail in the one situation where revocation matters, which is when your connection is being hijacked. All the major browsers already have a baked in revocation list that updates when there are major incidents. Chrome will just start pushing theirs outside of the normal browser update channel and stop on-demand CRL checks because those can't protect the user in an attack scenario; the soft-fail state is relied upon by too many existing bits of web infrastructure.
If the certificate is revoked... the Certificate you retrieve for validation can easily be for the bad one.
DNS has this happen all the time. A host changes IP... It can take several weeks before that propagates to the users.
Revocations need to be as close to immediate as possible, which is why OCSP was created... unfortunately, they didn't take into consideration what happens when a server is subject to a DDS due to everyone trying to retrieve the certification lists... Nobody has enough bandwidth to support it without failures.
But it's not like a local attacker intercepting communication at your end is the only possible option. What if the datacenter the server is hosted in or an ISP along the path has been compromised? What if the target site's DNS has been modified to point to the attacker? There are many possible ways that an attacker could cover only parts of the internet or only the specific target itself, still allowing full access to the CRLs and thus allowing them to do their jobs.
That said, I can't argue with the privacy point.
IMO since the privacy concern is legit and it is true that it's not as useful as some might have believed, it should be made optional rather than removing it outright. Even understanding the situations where it doesn't work, there are still situations where it does.
On that note, using CRLs alone rather than OCSP eliminates the privacy concern to a substantial degree as then the CA only knows you accessed a site using a certificate that points at that CRL, not which certificate you're using. Of course the tradeoff is that it requires downloading the whole list every time you need it, so a whole different can of worms comes up with caching versus the ability to rapidly revoke certs.
I used to get high on life, but I developed a tolerance. Now I need something stronger.
X509 certificates go back to July 3, 1988.
That makes certificates (and their revocation) 24 years old.
So yes, decades old.
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.
This is just a case of unsafe defaults. To fix this in Firefox go to Tolls - Options - Advanced - Encryption - Validation and check the box that says "When an OCSP server connection fails, treat the certificate as invalid."
This is probably what the default should be anyway. I cannot imagine a fingerprint scanner that just assumed everyone was authorized if the database went down. If it can't validate, then it isn't valid!
When you don't change default values in the browser (in case of FF at least), you just need to check one checkbox to make it treat unresponding OCSP servers as a validation error.
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
I bet Chrome won't be skipping over Google Analytics or their ad engine, which slows down my page breaking my experience something fierce.
Except for ending slavery, the Nazis, communism, & securing American independence, war has never solved anything.
Chrome: "We're not wearing eye-gear on the paintball field because we all shoot at torsos"
Banks: "That's nice. You're not playing on the paintball field without eye-gear."
Maybe also have the padlock be an animation like the "page is loading" icon. A padlock trying to lock closed.
Anyway, mu. The Certificate Authority infrastructure is fundamentally broken. Faulty by nature. Fussing with CRLs matters little when your browser already trusts a dozen discount CAs who either are not reporting break-ins or aren't even noticing them.
I have been running with security.OCSP.require set to true for a long time and haven't really noticed failures. Maybe the stated problem with CRL check timeouts is being overblown?
it is obvious from his blog post that he has little understanding of security. And is only interested in placing key functionality under Google control and maintaining a positive user experience.
.. imagine someone else gets their hands on such nice, helpful certificates.
Well, it's a Google product. From what I've seen so far, everything they do is about tapping your data. Not that I assume that is the intention here, but you can bet your rear end that someone will eventually realize that.
No thank you. Go and do some more evil elsewhere - not on my system.
A seat-belt isn't there to protect you if you drive at 200mph into the side of a building. If that's what you're doing, your day is going to be ruined no matter what.
Seat-belts are there to protect against the low hanging fruit of accidents. If you're driving 20mph and the neighbour's cat suddenly runs across the road, you break and the seat belt stops you and your passengers from getting a nasty bruise.
That's what it's for, and it works exceedingly well at doing that. If we get rid of seat-belts because they don't help in the 1% of cases, like when someone crashes into a building, then all we're doing is increasing dramatically the global accident rate on trivial incidents, like the cat example.
So I see the practical benefit, trying to reinstate the 'offline' nature so that CA hosting facilities do not become the bottleneck for various things. From a security perspective this seems bad...
CRL relies upon the CA knowing about all the certs that should be revoked. Notably, if someone managed to discretely get a CA's private key, and applies that advantage with any subtlty, then the certificate isn't even known to be issued by the CA, they can't revoke what they don't know about.
Compromising an architecture like OSCP is a little different. A compromise of a CA is necessarily much more blatant if you have to also compromise the OSCP service.
Really, the most practical answer is to go as much toward making a confirmed positive OSCP a requirement for 'secure', and fix the bad practice of 'server temporarily down' as good as 'it says things are ok'. Let market forces punish the CAs unable/unwilling to invest what is required for this to be valid. When you control the browser,it's a strange argument to say it's worthless because your own browser won't strictly enforce OSCP so you throw it out for a much-more-dangerous blacklist approach.
I will say in some of the larger userbases that distributed reputation system to double check the CA results makes sense. I just wouldn't want that to replace a CA situation, as it wouldn't scale to small sites well and there is a more clear mechanism to invalidate bad certificates with CA. Should require a true-positive OSCP and either no or good reputation information to be really secure.
XML is like violence. If it doesn't solve the problem, use more.
Chrome: "No more OCSP for us" :-)
Banks: "Dooiiiyyeeee can we have IE6 back, pretty pleeeease?"
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...
S/MIME is a transport protection, just like SSL. It is not meant to impart non-repudiation on the content of a mail. It is only meant to ensure integrity (signing) and confidentiality (encrypting) from the moment it is sent to the moment it is received. For this to work, the time between signing and validation (and/or encrypting and decrypting) must be "short". The receiving system should decrypt and validate the incoming message as soon as possible. The result of the signature validation should be remembered, so it is not necessary to do again. The message should be stored in its decrypted form. You should not rely on S/MIME to protect your message after it has been received by you. If you need to ensure integrity and confidentiality when storing the mail, that should be done by whatever is storing the mail (the mail server or the client locally) in a different manner, it is outside the domain of S/MIME.
Now, S/MIME implementations don't work that way, which is why you end up with the problems you have. For one thing, S/MIME is usually a function of mail client rather than the mail server which makes it difficult (but perhaps not impossible) to implement "S/MIME for transport only" model.