6 ms·

Chrome/Firefox aren't checking CA revocation lists

81 points by fastest963 13y ago

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.

nav1 13y ago
Yes it does. It's just not enabled by default.
- fastest963 13y ago
  How many people are going to check that box under "Advanced Settings"? 0.1%?
  - scrollaway 13y ago
    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.
    - fastest963 13y ago
      Worthless except when your cert key is stolen and you want to revoke the old one?
      - sp332 13y ago
        What good is it to revoke one, if it still works because no one checked the revocation list?
        fastest963 13y ago
        That's the whole point of me posting this...
    - iancarroll 13y ago
      How are they worthless?
      - msherry 13y ago
        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.
        iancarroll 13y ago
        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...
      - nullc 13y ago
        Beyond being seldom used, they also leak usage information.
        dfc 13y ago
        If you are leaking usage information with ocsp/crl checks you are also spewing out information via DNS requests.
  - snogglethorpe 13y ago
    Still, having that setting there means you can easily tell people to turn it on...
mbrubeck 13y ago
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/000329.html https://mail.mozilla.org/pipermail/firefox-dev/2013-April/00... https://mail.mozilla.org/pipermail/firefox-dev/2013-May/000334.html https://mail.mozilla.org/pipermail/firefox-dev/2013-May/0003... https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol https://en.wikipedia.org/wiki/Online_Certificate_Status_Prot... https://wiki.mozilla.org/CA:ImprovingRevocation https://wiki.mozilla.org/CA:ImprovingRevocation
- fastest963 13y ago
  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."
deleted 13y ago
[deleted]
agl 13y ago
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 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 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.
- fastest963 13y ago
  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.
  - 13y ago
joeyh 13y ago
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.
- dfc 13y ago
  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.
asmeurer 13y ago
https://code.google.com/p/chromium/issues/detail?id=361230 https://code.google.com/p/chromium/issues/detail?id=361230
- asmeurer 13y ago
  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 https://code.google.com/p/chromium/issues/detail?id=53
  - fastest963 13y ago
    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.

81 points by fastest963 13y ago

nav1 13y ago

Yes it does. It's just not enabled by default.

fastest963 13y ago
How many people are going to check that box under "Advanced Settings"? 0.1%?
- scrollaway 13y ago
  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.
  - fastest963 13y ago
    Worthless except when your cert key is stolen and you want to revoke the old one?
    - sp332 13y ago
      What good is it to revoke one, if it still works because no one checked the revocation list?
      - fastest963 13y ago
        That's the whole point of me posting this...
  - iancarroll 13y ago
    How are they worthless?
    - msherry 13y ago
      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.
      - iancarroll 13y ago
        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...
    - nullc 13y ago
      Beyond being seldom used, they also leak usage information.
      - dfc 13y ago
        If you are leaking usage information with ocsp/crl checks you are also spewing out information via DNS requests.
- snogglethorpe 13y ago
  Still, having that setting there means you can easily tell people to turn it on...

mbrubeck 13y ago

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/000329.html https://mail.mozilla.org/pipermail/firefox-dev/2013-April/00... https://mail.mozilla.org/pipermail/firefox-dev/2013-May/000334.html https://mail.mozilla.org/pipermail/firefox-dev/2013-May/0003... https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol https://en.wikipedia.org/wiki/Online_Certificate_Status_Prot... https://wiki.mozilla.org/CA:ImprovingRevocation https://wiki.mozilla.org/CA:ImprovingRevocation

fastest963 13y ago
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."

deleted 13y ago

[deleted]

agl 13y ago

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

fastest963 13y ago
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.
- 13y ago

joeyh 13y ago

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.

dfc 13y ago
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.

asmeurer 13y ago

https://code.google.com/p/chromium/issues/detail?id=361230 https://code.google.com/p/chromium/issues/detail?id=361230

asmeurer 13y ago
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 https://code.google.com/p/chromium/issues/detail?id=53
- fastest963 13y ago
  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.