Chrome/Firefox aren't checking CA revocation lists
Chrome isn't checking revocation lists anymore (source: https://www.imperialviolet.org/2012/02/05/crlsets.html) so for everyone reissuing keys today, their sites are still vulnerable for Chrome users, right?
I checked Google's own (custom) CRL and they don't have any serials from Comodo or Verisign's revocation lists, but they do have some from GoDaddy. Verified with https://github.com/agl/crlset-tools.
Update: Added Firefox to title based on mbrubeck's findings.
In order to attack an HTTPS connection, the attacker has to have MITM position against the victim: the ability to intercept TCP connections.
Such an attacker can obviously also block the CRL/OCSP lookup if one is made. Even with revocation checking enabled, no browser that I know of will fail a TLS handshake if the revocation check is blocked.
(You can configure Firefox to do this. Tools -> Options -> Advanced -> Encryption -> Validation, check the box for "When an OCSP server connection fails, treat the certificate as invalid" - so says https://wiki.mozilla.org/CA:OCSP-HardFail)
I claim that soft-fail revocation checking is basically nonsense. That's the point that I'm making in https://www.imperialviolet.org/2012/02/05/crlsets.html.
Making it hard-fail isn't viable: it makes OCSP servers a single point of failure for huge parts of the web. That's why Chrome has a CRLSet system that actually can achieve real goals. The attacker has to persistently MITM the client in order to block the CRLSet update.
The CRLSet is limited in size. I had hoped that CAs would use the reason code mechanism in CRLs to remove the "administrative" revocations that dominate their CRLs. (Those are revocations where there's no suggestion of compromise.) Some do, but most don't.
It's not true that the CRLSet doesn't include any Comodo or Symantec (who now own Verisign's old CA business) CRLs. In fact, Symantec/Verisign CRLs are the biggest contributor to the CRLSet.
But it's true that the CRLSet is limited in size. We focus on CRLs for CA and EV certificates. I don't think the world has a great answer to the revocation problem when certificates are valid longer and longer periods.
Current versions of Firefox also do not use CRL, if I understand correctly. It seems most modern browsers prefer OCSP instead, with CRL only as a fallback or not at all. You can find some of the rationale at these links:
https://mail.mozilla.org/pipermail/firefox-dev/2013-April/00...
https://mail.mozilla.org/pipermail/firefox-dev/2013-May/0003...
https://en.wikipedia.org/wiki/Online_Certificate_Status_Prot...
I'm hoping to see a chrome extension that flags every certificate issued before 2014/04/07 as insecure. In the meantime, I am switching to firefox to use certificate patrol for anything I care about.
undefined
Yes it does. It's just not enabled by default.