My next class:
LINUX Incident Response and Threat HuntingOnline | US EasternJan 29th - Feb 3rd 2025

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)

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

Keywords: certificate CRL HTTPS SSL
16 comment(s)
My next class:
LINUX Incident Response and Threat HuntingOnline | US EasternJan 29th - Feb 3rd 2025

Comments

I think this is a right time to redesign the SSL or Https because spamming is increasing rapidly.

Tom

Feb 8th 2012
1 decade ago

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.

Erik van Straten

Feb 8th 2012
1 decade ago

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.

Dom

Feb 8th 2012
1 decade ago

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

PC.Tech

Feb 8th 2012
1 decade ago

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

Feb 8th 2012
1 decade ago

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?

dsh

Feb 8th 2012
1 decade ago

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.

signal7

Feb 8th 2012
1 decade ago

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.

RichH

Feb 8th 2012
1 decade ago

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

Erik van Straten

Feb 8th 2012
1 decade ago

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.

Mysid

Feb 8th 2012
1 decade ago

Login here to join the discussion.


Top of page
Diary Archives