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."
Why? (Score:5, Insightful)
Why?
Re:Why? (Score:5, 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.
Re:Why? (Score:5, 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.
Re:Why? (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%?
False warnings (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.
Re: (Score:2, Interesting)
Re: (Score:2)
I probably should have said 'they', not 'we'. Thus my harping on the problem - not that I'm anywhere near where I'd need to be to have a chance to be listened to.
I wouldn't be revoking the certs unless they did something stupid like lost it or gave out their pin.
Re: (Score:2)
It's still a problem though. You would expect if you revoked a certificate to be able to give a timeframe in which the revocation should be applied (i.e. how long ago do I think it became compromised?)
Re: (Score:2)
S/MIME is a transport protection (Score:2)
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 m
Re: (Score:2)
The odds are infinitely higher than catching it when displaying no alerts at all.
Re:Why? (Score:4, Insightful)
When was the last time you so much as looked out a window when you heard a car alarm?
Re: (Score:2)
When was the last time you so much as looked out a window when you heard a car alarm?
The first few weeks after I got a new car..
Re: (Score:2)
The last time I heard one, which was many, many moons ago. It's not like it costs much to have a look. Just like it doesn't cost much to try again later, or press "ignore" when a CA doesn't respond.
"Good to know that Google knows, so I don't have to know." Haha.
Re: (Score:2)
Re:Why? (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.
Re: (Score:2)
Guessing you have no idea what it takes to keep a server running 24/7. There are thousands of things that can go wrong and bring down a server from simple errors or bugs to Denial-of-service attacks.
Re:Why? (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.
Re: (Score:3)
Oh come on, it doesn't have to be a single server. Plenty of web businesses are able to manage 24-7, it's not outside the wit of man.
Re: (Score:2)
Re:Why? (Score:4, Insightful)
Twitter as an example of reliability? Are you joking? You do know where the expression "fail whale" came from, right?
Re: (Score:3)
Yeah, but I bet twitter's "fail whale" page servers are up 99.999% of the time...
Re: (Score:2)
Given how much they charge for certificates they ought to be able to set up a decent server + backup server.
Re: (Score:3)
Re: (Score:2)
Guessing you have no idea what it takes to keep a server running 24/7. There are thousands of things that can go wrong and bring down a server from simple errors or bugs to Denial-of-service attacks.
Well people running other services (Internet trunks, DNS, many webistes) manage it. Granted it costs money, but I think this validates Google's action; either it should work and be used or don't bother
Re: (Score:3)
A CRL server is a mission critical server that should stay up 24-7.
In order for that to happen you'll need a significant monetary incentive based on uptime. Without that you're going to get a server that's up most of the time.
Re: (Score:2)
How about, "if your CRL isn't available, our browser rejects your cert and people can't get to sites that you sign?" Who is going to pay for certs at the same CA next year if your CA goes offline that it interferes with their customer base?
The monetary incentive is already there. Google is removing that incentive.
Re: (Score:2)
Google is removing that incentive.
Sounds like "Chrome and most other browsers" have already removed that incentive.
Re: (Score:2)
Re: (Score:2)
Internet Explorer can even be configured to demand CRL/OCSP verification, and fail the certificate if it fails.
Re:Why? (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.
Re:Why? (Score:4, Insightful)
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).
UI suggestion... ah, nevermind (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
I would think the best compromise is to treat inability to connect as passing unless configured to be paranoid.
Re: (Score:3)
But if the certificate was stolen from the Bank, it's their fault, not yours.
Fault is not particularly relevant when the parent comment was "Someone stealing your banking information is a pretty bad user experience, too." Sure, it's their fault. Sure, they'll eventually have to make it good. But, in the meantime, you're the one dealing with all the crap that's happened.
Re: (Score:2)
Re: (Score:2)
Maybe. If you have a good government they will force the bank to deal with all that crap for you or to refund you when their not doing so leads to your account being plundered.
Re: (Score:2)
And if I had wings, I could fly!
Re: (Score:2)
Re: (Score:2)
Me having wings or you being an airplane both strike me as more likely than a good bank these days.
Re:Why? (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:Why? (Score:4, Insightful)
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: (Score:3)
That's why the model going forward is going to be something like
http://convergence.io/ [convergence.io]
http://perspectives-project.org/ [perspectives-project.org]
http://patrol.psyced.org/ [psyced.org]
Re: (Score:2)
No, it really isn't. Numerous times on here those get brought up, and every time someone explains why they won't work. The problem, far from being technically flawed, is just that it's too damn complicated for the average user. Here's what really happens if these end up going the way you seem to expect:
1. Browsers ship with Convergence. No notaries are trusted by default. People get scared of angry warnings about "untrusted websites".
2. Browser makers become frustrated, see that there is a need for def
Re: (Score:2)
Why not read the blog post?
Or if you are too lazy to click a link think about it for a second. Hint: should every site with an SSL cert from X not work because X is unreachable for whatever reason right this second?
Re:Why? (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.
Re:Why? (Score:4, Insightful)
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: (Score:2)
And that isn't what the guy is suggesting, because???
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).
Re: (Score:2)
Treat it like plain text http in every way. Do the cookie go through http?
Re:Why? (Score:5, Insightful)
Re: (Score:2)
Re: (Score:3)
CAs get up to hundreds of dollars per certificate. Whatever they need to keep a damn static file with 100% uptime has been more than paid.
Re: (Score:2)
Re: (Score:2)
So X is going to keep my infrastructure up for me because I sepnd $20 on a cert?
Since the obvious case is I'm trying to access my own web server from inside my own network, but it's using https and our external connection is down for some reason. Heck, maybe the cert is on the firewall whose management interface I'm trying to get to over https so I can fix the cause of the external access problem.
Re: (Score:2)
"So X is going to keep my infrastructure up for me because I sepnd $20 on a cert?"
Yes, they should, because the are selling a service. If they can't keep their infrastructure up then people should not buy certs from them.
"Since the obvious case is I'm trying to access my own web server from inside my own network, but it's using https and our external connection is down for some reason. Heck, maybe the cert is on the firewall whose management interface I'm trying to get to over https so I can fix the cause o
Re: (Score:2)
Re: (Score:2)
Because you don't RTFA
Re: (Score:2)
That "just" leaves the DNS system as a possible valid target. You know, the system that's probably more important than SSL.
And nothing of value was lost... (Score:2)
What? (Score:4, Interesting)
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?
Re:What? (Score:5, Informative)
Re: (Score:2)
CRLs are revocation lists which used to be published by CAs and clients were able to periodically download.
As a concept they were replaced with OCSP (online certificate status protocol). Here the client requests the current status of a certificate each time they are presented with it. The idea was that it would be more timely and up to date and meant CAs didn't need to publish a complete list of revoked certificates.
Now it seems Chrome wants to go back to a bodged version of the old way of doing things wh
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: (Score:2)
CRLs fail unlocked because that's what the browsers set as the default to avoid inconvenience.
Now, if the CRLs are local, will they still fail unlocked if they're missing or corrupt? i.e. next virus target.
If so, then they've done nothing to help the fundamental problem of insecure security.
Re: (Score:2)
99.9999% of end users will never visit anything with a *.verisign.com domain.
There are over 2 billion internet users... so you're saying only 200 people in the world will visit that site? Is now a bad time to note that millions of websites have a 'Verisign Approved' widget on their site that has a referred URL back to the *.verisign.com domain?
Re: (Score:2)
Not for long, come Q2 this year that becomes "Norton Secure" and links back to norton.com.
Re: (Score:3)
Once it gets escalated up to 2nd, 3rd, 4th tier support at the ISP that $bigcustomer has no GOOG access, and the 4th tier engineer checks his BGP and its all good and is scratching his head in mystification as to why $bigcustomer can't access certain GOOG ip addrs, maybe, just maybe, he'll remember this /. thread and catch a MITM in progress. Maybe.
Re: (Score:2)
Re: (Score:2)
> So he admits Chrome is broken, so he doesn't fix it and blames the CA's . . makes sense.
If the CAs' blacklists worked reliably, then chrome wouldn't need to ignore when they were down. So it is the CAs' fault.
Re: (Score:2)
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?
You've made the classic mistake of taking the Slashdot headline seriously. The actual post [imperialviolet.org] doesn't say Chrome will stop using CRLs. It says they will be pushed to Chrome directly from Google. No one "admitted" that Chrome is broken. The entire system is broken. All major browsers will load an HTTPS site even if they cannot get the CRL via OCSP because doing otherwise would cause huge amounts of unnecessary breakage and just make users angry and confused. From the actual post:
So soft-fail revocation checks are like a seat-belt that snaps when you crash. Even though it works 99% of the time, it's worthless because it only works when you don't need it.
Great idea. (Score:3, Insightful)
And the solution, obviously, is not checking at all. Slick.
Re: (Score:3)
I'm guessing the fact that a top level certificate compromise is something that is to be ignored. We already went through this with a CA that got bankrupted due to security issues. Web browsers not dealing with revoked keys will just add significantly to the time that blackhats can MITM stuff.
The solution? I would say that SLCs (short-lived certificates) might be the best thing, with a mechanism to replace browser root keys periodically. Every time the browser is updated, CAs have new root keys. This w
Re: (Score:2)
This doesn't look like a bad idea... But the thing is, Google wants to get rid of on-the-fly verification of revocation certificates, and you suggest on-the-fly reception of short lived certificates, so it might run into similar issues as the current system. Remember, a revocation list is permanent, so you can just download the latest updates to it, which should not be too bandwidth intensive if you do it every time you start your browser. A list of active certificates could not be kept, and would have to b
Re: (Score:2)
No, the solution is checking at update time and storing the list of revoked certs locally so that you don't need to rely on the CLR server being available (which is something a man in the middle would be able to disrupt anyway).
Being Google (Score:2)
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"?
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:Being Google (Score:5, 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.
Re:Being Google (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.
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.
Re: (Score:2)
The worst change is that in order to have a secure browser you have to be using the current version of Chrome.
You seem to think they think this is a bad thing...
Re: (Score:2)
There's an unfortunately high coupling between security improvements, platform changes, and UI alterations in Chrome. The first means that the latest version is always desirable. The other two make the latest version undesirable. I can't be the only one who nearly went insane when Chrome started crashing every time you closed a youtube video a week or two back. I think they rolled out a workaround on youtube's side, and I don't know for sure that the root cause is Chrome updates vs. a latent bug that ha
Re: (Score:2)
Re: (Score:2)
You can add or remove any CA cert you want if you want to trust more (or fewer) CAs. Nothing requires you to leave the default set as is.
Re: (Score:2)
This. It should not be within the realm of Google's purview to rewrite standards on an adhoc basis.
A single decade...maybe one and a half. (Score:2)
"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 wa
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.
Comment removed (Score:5, Informative)
Re:He's right (Score:4, Insightful)
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: (Score:2)
This makes sense in the case described... (Score:2)
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 priv
Re: (Score:2)
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?
What if someone's running a phishing site using fraudulently-obtained EV certificates that display a nice pretty green message? That's not normally possible because EV certificates normally mandate OCSP checks that fail secure, but with these changes once an attacker gets their hands on one they'll have plenty of time to exploit it...
A better fix (Score:3)
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!
Re: (Score:2)
It could be that OSCP server was up but the virus that was redirecting your DNS decided to block the request so that you would disable the setting.
All Banking sites will now exclude Chrome (Score:3)
Banks: "That's nice. You're not playing on the paintball field without eye-gear."
Banks are tyros when it comes to browser security. (Score:2)
Chrome: "No more OCSP for us" :-)
Banks: "Dooiiiyyeeee can we have IE6 back, pretty pleeeease?"
False choice (Score:3)
What a boneheaded argument (Score:3)
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.
Re: (Score:2)
That's what it's for, and it works exceedingly well at doing that.
The problem is the attacks where it's useless are far more prevalent than the ones where it does any good.
It only does good if the attacker compromises near the server. This is relatively rare.
If the attack either comes as a IP layer MITM (attacker is providing a router to victim) or DNS poisoining, then *all* servers including OSCP are fair game.
The problem with the rant on soft-fail is it ultimately places the fault on OSCP and not on the *soft* aspect of failing and goes on to recommend a blacklist str
Replacing CRL with a CRL... (Score:2)
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 arch