Chrome to stop checking Certificate Revocation List (CRL)?
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
LINUX Incident Response and Threat Hunting | Online | Japan Standard Time | Oct 21st - Oct 26th 2024 |
Comments
Tom
Feb 8th 2012
1 decade ago
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.
Erik van Straten
Feb 8th 2012
1 decade ago
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.
Dom
Feb 8th 2012
1 decade ago
.
PC.Tech
Feb 8th 2012
1 decade ago
- Ze0h4x
Ze0h4x
Feb 8th 2012
1 decade ago
dsh
Feb 8th 2012
1 decade ago
signal7
Feb 8th 2012
1 decade ago
RichH
Feb 8th 2012
1 decade ago
Note that more often than not, the first thing you do over such a connection is identify _you_ by providing logon credentials.
Erik van Straten
Feb 8th 2012
1 decade ago
If no DNSSEC and no OCSP, then the cert should be treated as invalid.
Mysid
Feb 8th 2012
1 decade ago