4 ms·

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 c

by 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.
- agl 13y ago
  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 :(
zaroth 13y ago
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.
derefr 13y ago
Would it be feasible to make OCSP errors abort the TLS connection if it only applied to sites that have requested HSTS?
- agl 13y ago
  We did this by mistake once and got bug reports about PayPal being flakey. (PayPal was an early HSTS adopter.)
  - fastest963 13y ago
    Understandable, admins would just have to start treating OCSP like they do DNS (if it fails you can't visit site).
    - derefr 13y ago
      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?
      - is39 13y ago
        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-dns/ https://datatracker.ietf.org/doc/draft-pala-rea-ocsp-over-dn... http://tools.ietf.org/html/draft-pala-rea-ocsp-over-dns-00 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://bugzilla.mozilla.org/show_bug.cgi?id=611836 https://datatracker.ietf.org/doc/rfc6961/ https://datatracker.ietf.org/doc/rfc6961/ --igor
tzs 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. 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.
- agl 13y ago
  > 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.
pronoiac 13y ago
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.
adef 13y ago
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...).
paulirish 13y ago
For reference: Chromium ticket for this issue: https://code.google.com/p/chromium/issues/detail?id=361230 https://code.google.com/p/chromium/issues/detail?id=361230 (Closed as WONTFIX for the same reasons)

by agl 13y ago

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.

agl 13y ago
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 :(

zaroth 13y ago

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.

derefr 13y ago

Would it be feasible to make OCSP errors abort the TLS connection if it only applied to sites that have requested HSTS?

agl 13y ago
We did this by mistake once and got bug reports about PayPal being flakey. (PayPal was an early HSTS adopter.)
- fastest963 13y ago
  Understandable, admins would just have to start treating OCSP like they do DNS (if it fails you can't visit site).
  - derefr 13y ago
    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?
    - is39 13y ago
      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-dns/ https://datatracker.ietf.org/doc/draft-pala-rea-ocsp-over-dn... http://tools.ietf.org/html/draft-pala-rea-ocsp-over-dns-00 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://bugzilla.mozilla.org/show_bug.cgi?id=611836 https://datatracker.ietf.org/doc/rfc6961/ https://datatracker.ietf.org/doc/rfc6961/ --igor

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

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

pronoiac 13y ago

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.

adef 13y ago

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

paulirish 13y ago

For reference: Chromium ticket for this issue: https://code.google.com/p/chromium/issues/detail?id=361230 https://code.google.com/p/chromium/issues/detail?id=361230 (Closed as WONTFIX for the same reasons)