Google will drop online checks for revoked website encryption certificates in future versions of its Chrome browser after it decided that the process no longer offers any tangible benefits. For about a decade now, browsers check the validity of a website's secure sockets layer (SSL) certificate by polling online revocation …
It strikes me that the revocation check logic is wrong. There are three possible results:
(a) Revocation check OK; certificate not revoked -> OK, proceed to the site;
(b) Revocation check OK; certificate revoked -> warn the user (or block the site and tell the user why);
(c) Revocation check fails (no result) -> warn user but allow the user to proceed "under caution" to the site.
Perhaps the URL bar background could be GREEN, RED and AMBER respectively in the three cases.
That would make too much sense
It seems the prevailing wisdom these days is that users are idiots who should not be giving any choices or information. Thus (c) clearly is an unacceptable solution.
Most users are idiots when it comes to security. C would be unacceptable in any firewalled environment as the browser would never be able to check for revocation and so the user would always get an error message. The biggest problem with giving a choice using UAC as an exmaple is that the user will almost always press Yes.
Paris: Because she'll say yes to anything.
Just how long...
... before someone crafts malware to mess with the revoked certificate list locally to whitelist their nefarious certificate for www.almost_but_not_quite_the_real_domain_for_a_bank.com
as far as I know the CRL's are signed by a the CA. So this would require the hacker to also be emulating the root ca. In that case surely they might as well just man in the middle with a cert that looks genuine.
If they can sign one in a M-i-t-m attack...
... then they can spew it widely making it harder to eradicate.
You said "Halting access to a HTTPS-secured website if a revocation check failed would leave users unable to connect to sites if the relevant CA was down for any reason, another bad idea."
How did you come to that conclusion? If you are simply referring to the inability of CAs to scale their CRL servers appropriately to handle the traffic; that doesn't make it a bad idea, but simply a poor, but typical, implementation. If not, then you've just said that security can be unimportant.
Also, I surmise that Google is doing this in order to be able to to deny the CA's the ability to track the use of their customers' websites, which they can do by the number of CRL queries (kind of).
Apple was heavily criticised - by the likes of Sophos, etc - for not turning on automatic OCSP certificate checks on Safari by default, until they changed that setting in OSX Lion.
Now Google goes and turns it off in their browser...
They're relying on the browser to know what's good and what's bad. Every time something like this blows up it takes a few days for an update to be pushed out and you're open to attack until the next browser update. It also takes a few days for the press to get hold of it.
I've got Options > Advanced > Encryption > Validation > "When an OCSP server connection fails, treat the certificate as invalid set" set and if something fails I turn it off for a short while (after trying again and checking the IT news). Paranoid, much?
Oh, that's Firefox...
So, they complain about a seatbelt that snaps in SOME crashes ... and replace it with a pre-snapped one guaranteed to have failed already regardless? *headdesk*
Catching the use of a revoked certificate is good. Even if it sometimes fails, it's better than nothing! I'm wondering if Google have an ulterior motive of sorts here, given their recent obsession with speeding up HTTPS and SPDY, including taking interesting shortcuts in SSL?
Maybe their system is wonderful - but I'd still rather have my browser check for revocation than not. Defence in depth.
@James: What Google Wants
Is to track behaviour as closely as possible. All major browsers already post each and every URL to either Google or Microsoft, including Firefox, btw. All in the name of "phishing protection", of course. Don't believe it ? Do a little wiresharking.
I guess what they want to do is to redirect the revocation traffic to a Google datacenter. And mine all the server names, of course.
Quis custodiet ipsos custodes?
At what point does Chrome's update system get subverted and the certificate list get manipulated?
If the problem is with what to do with checks that fail because they can't be completed then you need to reengineer that path. Caching might be part of the solution and the browser makers are indeed in a good position to be part of a public key infrastructure to distribute and update such lists or CA public keys, much as they now provide synchronisation services. Of course, any such approach is also open to subversion at some point in the chain. So, just as browsers are eminently suited to being gatekeepers they just as suitable to be the target for attacks through malware. Currently, I can't think a of a truly secure way to bootstrap the process without using an external channel such as a smartcard.
Bzzztttt - WRONG....
" "Microsoft, Opera and Firefox also push software updates for serious incidents rather than rely on online revocation checks."
Chrome is basically doing when Opera has done for a long while.
Except they're not
If I understood that Opera blog post correctly, they're basically saying that their browser does perform CRL and OCSP checks, and does "downgrade the security level" of a site if revocation checks cannot be performed (in contrast to the default settings in Chrome and Firefox, which carry on regardless if a revocation check cannot be performed).
However, all that happens when a site has its security level "downgraded" is that the address bar doesn't show a padlock. This doesn't actually stop people from using the site anyway, or stop scripts from running, etc. - so, basically Opera might as well do nothing at all.
They're all currently worse than useless (at default settings, at least - Firefox *can* be configured to treat OCSP responder failures as fatal), but the solution is simply to make CRL and OCSP checks mandatory, with browsers throwing up errors if the checks can't be performed. Google are re-inventing the wheel, when really all they need to do is take the one they've got and sand it down a bit so it rolls more smoothly.
Very disturbing and illogical move.
The reasoning behind this change makes some sense IMO. If you cannot rely on the CRL distribution points being available then it makes sense to try and solve this problem. We all know that Google has bandwidth to spare here.
However; this also poses the question how these certificates got into Chrome in the first place. Or maybe even raises the question why they haven't been removed as soon as it became apparent that these CA's used unreliable CRL distribution points?
This is a disturbing move from Google because it totally negates the intended effect of these CRL lists in the first place. Namely: giving CA's a 'last resort' to revoke certificates ASAP. As soon as a CA discovers a major hole somewhere then there is no time to wait for a browser manufacturer to push its next update. We need those warnings instantly!
A lot of people are full of talk when it comes to internet security, but when the big bucks start talking it all becomes different again... How surprising indeed!
Instead of working around these problems I think Google would have been better off by enforcing their security policies. If your aim is security and someone involved doesn't meet the required expectations then normally you don't lower your standards; you tell the involved parties to stick with the program instead!
EDITOR:A couple of things
1. Suggestion: make mention of Diginotar a link to an article about it (like http://www.theregister.co.uk/2011/09/20/diginotar_bankrupt/ )
2. In "Langely is proposing a more lighter weight method of ...":
"more lightweight" or "lighter-weight" would be more better English.
Look people, we're 50ms faster than rivals on HTTPS
Come on Google... Don't be evil ?
SSL is mostly money for old rope
The non-EV/domain verified SSL business is a right old rip off and a big cartel designed to allow a few heavy weights to roll in the cash.
If I can buy a basic SSL certificate for any domain name that has a registrar published owner name, address and postcode and have it in my paws inside 10 minutes, with bugger all checks, why do we need to pay Verisign et al for the pleasure of renewing it every year. It's a joke.
If all you want is a secure channel and don't give a crap about verification then why should users have to pay for something as basic as that? Surely that should be a basic function of the web these days now without having to pay for it. I don't pay anything for SSH why should I pay for basic HTTP encryption.
I can understand paying for EV SSL's, you need to have humans (hopefully) involved in the screening process, but then how good is the screening process?
Also when average Joe happens to look up at the green EV indicator next to the address bar does he even comprehend what it means?
I think it's time to re-think the whole SSL infrastructure because it's rotten to the core.
SSL and SSH
But it's essentially the same if you self-sign your SSL certificates, for free.
First time you connect to a new SSH server the client asks if you trust it's key. A web browser does the same if you connect to a web server with a self-signed certificate (with a few more checkboxes and warnings)
The issue is the same, there's no good way for the user to trust the other side's certificate without someone/something else vouching for it. That's what you pay for.
yeah but sort of
1 - if all you want is encryption. No need to to bother with a CA.
2 - the purposes of the CA is to establish trust - the encryption is a by product really. However the sales and marketing beef sell "secure / encryption blah blah" because its difficult to sell certified assurance/trust.
The certificate is meant to give assurance that the entity you are sending data to has had its identity validated by a trusted third party. The third party is "trusted" because they are audited annually and have to provide those reports to the browser programmes for their roots to be in the browser.
in relation to 2. the limited identity validation by low end certs is a real pain and should be stopped.
The other approaches are dependent on what the CA puts in its CPS and/or relying party agreements. So then end user should only "trust" based on what the CA has done to validate the identity. - Almost no-one does this. I know very few places that have read a CPS or the relying party agreements. Average Joe certainly doesn't if ever to my knowledge.
The core does have problems. For instance, legacy roots provide ubiquity across browsers and this creates a cartel scenario to some extent. IMO all roots in the browser program should have a shelf life (and actually expire and be removed), and that all CA's operate on a level playing field by standardising validation procedures for SSL certs.
Hearing about CA's that bought other CA's for their root certs that "still work in IE3/4" is nuts. Those browsers shouldn't be the reason we have certs that are so old still in use.
Standardised validation, "legal opinion" option should be phased out. You either prove your identity or you don't get a EV cert. validation is substantial and the CA's do take it really seriously. However EV also introduced new roots. If all other SSL certs could be switched off. We could re-engineer our CA's only to issue EV without necessarily having to cling on to CA's that are not doing a good job.
I don't want to choose!
I'd like to see both. I'd like google to roll up the revocation lists and distribute them via software update so they can be checked first *and* I'd like the online checks made.
Is that so hard?
But but but
"The median time for a successful OCSP check is ~300ms and the mean is nearly a second. This delays page loading and discourages sites from using HTTPS. They are also a privacy concern because the CA learns the IP address of users and which sites they're visiting.
That's 300 ms extra that Google can use to push even bigger ads to you!
Not to mention only Google should be allowed to record the IP addresses of its users.
Google has just found another way to track your online activity
Why ask the CA if a certificate is valid sending it the URL you're visiting? Tell Google instead...
What if the current certificates were replaced with ones that only last for 24 hours; the logic would be that the server, which should have better access to the internet than the client, has to renew every 24 hours in order to stay "Certified Genuine".
This would mean that the current browser logic can be simplified to "if certificate expired, then [warn]/[don't connect]".
The infrastructure for key maintenance would increase traffic a little, but the total would decrease because the browser doesn't need to make multiple connections to validate the certificate.
Certificate costs would need to increase a little, but security isn't free and the certificate authorities would at least have more to do than just renew every year/decade.
The old and new systems can coexist, with browser logic warning based on certificate expiry date: long expiry being not as good as <24 hour expiry.
High security applications could even step up to one or two hour recycling to increase trust levels.
The original system was based on poorer bandwidth and less browser traffic, and the browser doing a lot of the work; this would move the load to the certificate servers and the web servers, which should both have rock solid connectivity or they wouldn't be able to do their jobs.
SSL is BROKEN
SSL is broken; the 600+ CAs, in whom we are supposed to trust implicitly forever, are not all trustworthy. Perhaps a new method of certificate verification, such as Convergence, http://convergence.io, would help.
- Does Apple's iOS make you physically SICK? Try swallowing version 7.1
- Fee fie Firefox: Mozilla's lawyers probe Dell over browser install charge
- Pics Indestructible Death Stars blow up planets with glowing KILL RAY
- Video Snowden: You can't trust SPOOKS with your DATA
- 166 days later: Space Station astronauts return to Earth