Posted
by
timothy
on Tuesday February 07, 2012 @11: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."

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.

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.

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

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.

So you're misusing the system, and complaining. When you revoke the old cert, you are stating that it is no longer to be trusted. And now you complain when it says "don't trust this"? I guess a car analogy: (Where I live, you are required to have proof of insurance stickers on your license plate.) You give a properly insured car to your buddy. 2 days later you go and remove the insurance stickers from the car. A week later, your friend is pissed off because the cops gave him a ticket for being uninsu

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

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

Pointing at the wrong failure. CRLs aren't the problem here. The CA that's publishing the CRL is. If the user is validating certs, and the cert cannot be validated, then they cannot know that they are dealing with Bob's Computer Bits, or Dewey Screwem and Howe.

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.

A CRL is basically a flat file.
It should not be difficult to make it available 24x7 - at least for someone who charges outrageous amounts of money in exchange for basically digitally signing a couple of bytes.

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

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.

Perhaps they mean that the connection to the CRL/OCSP server fails for some reason? Fact is, there are a LOT of reasons why getting a response might fail, that has absolutely no relation to whether the server is up or not. There are Internet routing issues for the ISP of the servers (that should be able to be handled). There are routing issues for the users of the browser. There are hacks on the users' system that prevent hitting that site. There are intermittent issues with connectivity due to commun

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.

Right, you're saying that only about 20% of the sites that fail the security check are legitimate? So it makes sense to ignore the check in the remaining 80% of sites that contain malware and phishing setups. That's crazy.

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.

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.

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

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.

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

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.

"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

Just FYI, depending on exactly when in 2010 it was hacked, Verisign may not have been in the certificate business. Symantec purchased the business in May of 2010, and IIRC the operational transfer happened pretty quickly.

That "just" leaves the DNS system as a possible valid target. You know, the system that's probably more important than SSL.

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

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.

So he admits Chrome is broken, so he doesn't fix it and blames the CA's . . makes sense.

Chrome will instead rely on its automatic update mechanism to maintain a list of certificates that have been revoked for security reasons. Langley called on certificate authorities to provide a list of revoked certificates that Google bots can automatically fetch.

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

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

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?

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.

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.

So he admits Chrome is broken, so he doesn't fix it and blames the CA's . . makes sense.

Chrome will instead rely on its automatic update mechanism to maintain a list of certificates that have been revoked for security reasons. Langley called on certificate authorities to provide a list of revoked certificates that Google bots can automatically fetch.

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.

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

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

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

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.

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.

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.

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

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.

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.

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

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!

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.

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.