Chrome/Firefox aren't checking CA revocation lists
6 comments
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.
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.
So the million odd revocations of class 1/2 DV certificates that have been going on the last couple days, are basically going no-where, right?
I mean, by all means, rotate your key and get a new cert, but my guess is CRLs cannot handle making space for a majority of SSL'd domains in the list.
I don't want my browser hanging up a secure page load while it downloads that file... More to the point, I don't want a million dot com revocations getting in the way of my browser learning about that "Major Root CA" that was compromised last week.
I mean, by all means, rotate your key and get a new cert, but my guess is CRLs cannot handle making space for a majority of SSL'd domains in the list.
I don't want my browser hanging up a secure page load while it downloads that file... More to the point, I don't want a million dot com revocations getting in the way of my browser learning about that "Major Root CA" that was compromised last week.
Would it be feasible to make OCSP errors abort the TLS connection if it only applied to sites that have requested HSTS?
We did this by mistake once and got bug reports about PayPal being flakey. (PayPal was an early HSTS adopter.)
Understandable, admins would just have to start treating OCSP like they do DNS (if it fails you can't visit site).
A thought: given that admins already have something that they treat like DNS--which is to say, DNS--could certificate revocations be distributed as DNS TXT records, and thus reuse all the caching infrastructure DNS currently implies?
I think this would be a good approach on many levels.
It appears there is already an (expired?) internet draft for this: https://datatracker.ietf.org/doc/draft-pala-rea-ocsp-over-dn... http://tools.ietf.org/html/draft-pala-rea-ocsp-over-dns-00
But i could not find any browser support or even plugins.
I guess all current development is behind DANE and/or multi-OCSP-stapling; second one has some chance of being deployed soon.
https://bugzilla.mozilla.org/show_bug.cgi?id=611836 https://datatracker.ietf.org/doc/rfc6961/
--igor
It appears there is already an (expired?) internet draft for this: https://datatracker.ietf.org/doc/draft-pala-rea-ocsp-over-dn... http://tools.ietf.org/html/draft-pala-rea-ocsp-over-dns-00
But i could not find any browser support or even plugins.
I guess all current development is behind DANE and/or multi-OCSP-stapling; second one has some chance of being deployed soon.
https://bugzilla.mozilla.org/show_bug.cgi?id=611836 https://datatracker.ietf.org/doc/rfc6961/
--igor
For reference: Chromium ticket for this issue: https://code.google.com/p/chromium/issues/detail?id=361230 (Closed as WONTFIX for the same reasons)
First of all, thanks for the reply. I wasn't trying to imply that Chrome/Firefox we're wrong in not checking. I understand your points against it; I'm just saying that if people revoke their old certificates today (because they might've been compromised) someone can still MITM pretend to be any of those websites if they actually got the key. Lower scope but still a problem, especially if your cert lasts for 3+ years.
I was using crlset-tools to test the list against an intermediate Comodo CA and the intermediate/anchor certs for Versign and it didn't return any results. I did the same thing for DigiCert and it did return some, so I assumed what I was doing was correct.
I was using crlset-tools to test the list against an intermediate Comodo CA and the intermediate/anchor certs for Versign and it didn't return any results. I did the same thing for DigiCert and it did return some, so I assumed what I was doing was correct.
I certainly believe that you're correct to question the utility of revocation.
We don't have all CRLs for all CAs (sadly). Some CAs have also asked for the list not to be published so there's no list of the URLs that we do crawl either :(
We don't have all CRLs for all CAs (sadly). Some CAs have also asked for the list not to be published so there's no list of the URLs that we do crawl either :(
> 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.
This is not at all obvious to me. Suppose you wanted to steal credit cards. The best place to do your MITM would be at the payment processor's connection to the net.
The clients doing the CRL/OSCP lookup will be connecting to the certificate authority, not the payment processor, for this. The MITM won't see them in most cases.
People who do their MITM close to the client can probably stop CRL/OSCP lookup, of course.
> Such an attacker can obviously also block the CRL/OCSP lookup if one is made.
This is not at all obvious to me. Suppose you wanted to steal credit cards. The best place to do your MITM would be at the payment processor's connection to the net.
The clients doing the CRL/OSCP lookup will be connecting to the certificate authority, not the payment processor, for this. The MITM won't see them in most cases.
People who do their MITM close to the client can probably stop CRL/OSCP lookup, of course.
> Suppose you wanted to steal credit cards. The best place to do your MITM would be at the payment processor's connection to the net.
In that situation the attacker can pass DV checks as the server and so can get new certificates issued to themselves. Or maybe they stock up on certificates before attacking and use OCSP stapling to run out 7 days per certificate.
Basically, everything falls apart in that situation already.
In that situation the attacker can pass DV checks as the server and so can get new certificates issued to themselves. Or maybe they stock up on certificates before attacking and use OCSP stapling to run out 7 days per certificate.
Basically, everything falls apart in that situation already.
Then we should just all agree to treat certificates issued before 08/04/2014 to be invalid for everyone.
It will be a day or two of complete mess but given the scale of the exploit it is not crazy to consider every single certificate used before this date to be insecure.
And this way we don't rely on broken revocation mechanism. And it will force sys admins to follow good practice (for instance, the public lab I work for still have not fixed the heartbleed bug on our central auth server and they are not yet convinced it is necessary to regenerate the certificates...).
Can you use a bloom filter against the CRL/OCSP, then test possible matches against the OCSP? I don't have numbers handy, but that could potentially improve privacy, speed, and bandwidth concerns.
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...
https://wiki.mozilla.org/CA:ImprovingRevocation
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...
https://wiki.mozilla.org/CA:ImprovingRevocation
From my understanding of the source I posted they're removing OCSP support as well: "There are two protocols/formats involved: OCSP and CRL, although the differences aren't relevant here."
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.
Who are you and what did you do with the real joeyh? The real joeyh hopes for a chromium extension and switches to iceweasel in the interim.
The Chromium team seems to have an all-or-nothing policy when it comes to security. c.f. https://code.google.com/p/chromium/issues/detail?id=53
For that bug at least they're now forcing the OS login before looking at the passwords in the Settings page. Not perfect but something.
[deleted]
Yes it does. It's just not enabled by default.
How many people are going to check that box under "Advanced Settings"? 0.1%?
Unlikely to be that high. The 0.1% that may dig in those advanced settings is likely the same 0.1% that disabled the thing back when it was enabled by default. CRLs are worthless.
How are they worthless?
They're worthless because clearly no one is using them. They may theoretically be useful, but it doesn't matter if they're never put into practice.
Do you mean nobody on the CA side or the end user side?
CA's suspend certificates all the time - instant e the scam site had theirs pulled a few weeks ago...
Worthless except when your cert key is stolen and you want to revoke the old one?
What good is it to revoke one, if it still works because no one checked the revocation list?
That's the whole point of me posting this...
Still, having that setting there means you can easily tell people to turn it on...
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.