Internet Storm Center
Training
Certification
Cyber Security Graduate School
Security Awareness Training
Computer Forensics
Penetration Testing
IT Audit
Software Security
Chrome to stop checking Certificate Revocation List (CRL)?
Published: 2012-02-08,
Last Updated: 2012-02-08 03:25:57 UTC
by Jim Clausing (Version: 1)
16 comment(s)
Last Updated: 2012-02-08 03:25:57 UTC
by Jim Clausing (Version: 1)
There was a post on Ars Technica yesterday, that led back to another blog post from Sunday that suggests that Google Chrome will stop doing CRL checks at some point in the not too distant future. This has led to some interesting debate because the CRL mechanism has largely been ineffective. For a public key infrastructure (PKI) such as HTTPS to work, there must be an effective way of verifying the validity of the certificates. Due to the number of Certificate Authority (CA) breaches in recent years we'd all like a fast and effective method of taking compromised certificates out of play. During the highest profile breaches, all the major browser vendors simply pushed new versions of the browser with the root certificates from the breached CAs removed, in part because the browsers by design fail open (allow the connection) if they are unable to verify the certificate. So, is this a big deal? Is it the right way to go? Is it time to rethink/redesign/replace SSL or HTTPS? What do you think?
References
http://arstechnica.com/business/guides/2012/02/google-strips-chrome-of-ssl-revocation-checking.ars
http://www.imperialviolet.org/2012/02/05/crlsets.html
---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu
Comments
I think this is a right time to redesign the SSL or Https because spamming is increasing rapidly.
posted by Tom, Wed Feb 08 2012, 05:26
CRL/OCSP checking is indeed flawed.
For example, CLS/OCSP URLs are in the certificate itself; if a CA attacker is able to generate certificates for webservers at will, chances are that he can also specify CRL/OCSP URLs (so these URL should have been included in the _parent_ certificate). Furthermore, CRL lifetime tends to be way too long, and OCSP has privacy issues. And there are more problems.
However, I've enabled mandatory OCSP checking in Firefox about 2 years ago and have experienced only a few problems. If this setting would have been _enforced_by_default_, the system would have been much more reliable by now. So, IMHO removing it is a bad idea.
We urgently need a redesign of the public PKI system and the way CA's work (see also http://www.h-online.com/security/news/item/Trustwave-issued-a-man-in-the-middle-certificate-1429982.html) and the way web browsers inform users about a level of trust. Basically https and SSL/TLS are not broken, however some minor changes may be needed to implement the major changes in PKI and web browsers that I refer to above.
For example, CLS/OCSP URLs are in the certificate itself; if a CA attacker is able to generate certificates for webservers at will, chances are that he can also specify CRL/OCSP URLs (so these URL should have been included in the _parent_ certificate). Furthermore, CRL lifetime tends to be way too long, and OCSP has privacy issues. And there are more problems.
However, I've enabled mandatory OCSP checking in Firefox about 2 years ago and have experienced only a few problems. If this setting would have been _enforced_by_default_, the system would have been much more reliable by now. So, IMHO removing it is a bad idea.
We urgently need a redesign of the public PKI system and the way CA's work (see also http://www.h-online.com/security/news/item/Trustwave-issued-a-man-in-the-middle-certificate-1429982.html) and the way web browsers inform users about a level of trust. Basically https and SSL/TLS are not broken, however some minor changes may be needed to implement the major changes in PKI and web browsers that I refer to above.
THIS HAS ALL BEEN FIXED !!!
http://convergence.io/
Convergence - get the Firefox plugin, and you're protected from a lot (but never all) of the problems with SSL authenticity.
Check out Moxie Marlinspike' (author of SSLsniff) excellent Blackhat presentation which explains how 'Convergence' fixes this problem.
http://youtu.be/Z7Wl2FW2TcA
Dom
PS. Yeah, never everything 'fixed', but at least we have a much better solution that the current CA mess.
http://convergence.io/
Convergence - get the Firefox plugin, and you're protected from a lot (but never all) of the problems with SSL authenticity.
Check out Moxie Marlinspike' (author of SSLsniff) excellent Blackhat presentation which explains how 'Convergence' fixes this problem.
http://youtu.be/Z7Wl2FW2TcA
Dom
PS. Yeah, never everything 'fixed', but at least we have a much better solution that the current CA mess.
Google says "this", Google says "that". MS says "this". MS says "that"... Are we tired of bowing to the monopoly every time they sneeze - yet?
.
.
Dom is right, convergence (Or something like it) is what we need to work towards. There is no "Trust" or "Do not trust," but rather "I trust you 90%."
- Ze0h4x
- Ze0h4x
PCTech, While I can understand your point, these are the major players. They hire some of the best technical minds and provide, for most of us, the practical applications we use on a day to day basis. I appreciate all that they've done. Accept it or not, these guys propose standards, refine them in stds groups and implement them into their products. Do they have a commercial interest? Sure, but at least we are progressing. What are the alternatives?
The problem we've been dealing with for a *very* long time is the complexity and expense of this system. To get users to use it the way it was intended, it needs to be cheaper and simpler. I shudder at the $250+ cost my department forks over multiple times a year for what amounts to be a very small digital file. For internal sites where we want to encrypt the connection, but don't really have a need to verify identity, this system is very cumbersome and requires frequent administrative overhead (getting client computers to trust the certificates as well as renewing the certificates on a regular basis). Overall, I want something simpler and more cost effective.
There is news from H-Security and elsewhere of requests to Mozilla to remove Trustwave's root certs. I would 100% agree with this action. Put them out of business. They sold trust, they intentionally violated it at least in principle (even while promising it didn't really matter). They should no longer have our trust, end of story.
@signal7: why would you want to encrypt a connection if you're not sure who you're talking to?
Note that more often than not, the first thing you do over such a connection is identify _you_ by providing logon credentials.
Note that more often than not, the first thing you do over such a connection is identify _you_ by providing logon credentials.
I suggest DNSSEC validation as an alternative to CRL, for HTTPS.
If no DNSSEC and no OCSP, then the cert should be treated as invalid.
If no DNSSEC and no OCSP, then the cert should be treated as invalid.
I suspected the CA PKI was broken, then came EV certs, confirmed. Convergence looks to follow the PGP approach. Better trust model there. Still a problem with common man understanding either way. Just click OK and it works, "problem solved" right? The carbon machine is far more complex than the silicon machine.
Before you can "move on" you need to know where you are going to. Until you have a better alerternative, that is significanlty support across Major Browser vendors that currently rely on Revocation List to some degree, then you are likely stuck. I would guess IE, Firefox, Chrome, Opera and Safari support Revocation lists ? If so each browser vendor can go their own way, but have to develop a method if they move away from the current standard (or agree to a new standard).
If we're trying to validate a domain where do things like domainsbyproxy fall? - If you're not willing to put your name and POC information behind your domain I don't want to trust you.
This posting is rather misleading. Following the links and reading the article shows that Chrome is thinking of replacing OCSP with their own CRL mechanism, due to latency issues.
They are still planning on importing CRLs from cert authorities via a crawling mechanism.
They are still planning on importing CRLs from cert authorities via a crawling mechanism.
OCSP came about because CRLs became too big to constantly download and consult.
I believe OCSP doesn't truly tell you if a certificate is valid. It only tells you if a valid certificate exists with the same serial number. There is nothing to stop a compromised certificate authority from signing a duplicate certificate with a previously existing serial number.
I believe OCSP doesn't truly tell you if a certificate is valid. It only tells you if a valid certificate exists with the same serial number. There is nothing to stop a compromised certificate authority from signing a duplicate certificate with a previously existing serial number.
I believe the browser must not allow the website access in case the certificate is not valid or expired or fishy.....Only this can ensure that innocent endusers do not fall prey to the attackers. This will also ensure that the organisations give high importance to the certificates and the whole PKI gets developed and may get strong.
New Comments closed for all Diaries older than two(2) weeks
Please send your comments to our Contact Form
Diary Archives
