4 ms·

The standard explanation for this is https://www.imperialviolet.org/2012/02/05/crlsets.html https://www.imperialviolet.org/2012/02/05/crlsets.html The short ve

by nialo 12y ago

The standard explanation for this is https://www.imperialviolet.org/2012/02/05/crlsets.html https://www.imperialviolet.org/2012/02/05/crlsets.html The short version is that any attacker against whom certificate revocation might matter is by definition in a position to MITM connections, and can simply interrupt the certificate check.

claudius 12y ago
And the correct interpretation of ‘interrupted revocation check’ is ‘invalid certificate’. Now, of course there’s the problem that the CAs are apparently unable to provide constantly-running OCSP servers, making such an interruption more likely to be due to technical inadequacy of the CA than due to an ongoing MITM attack, but that is first and foremost a problem of the CAs, not of a browser vendor.
- lomnakkus 12y ago
  OTOH that just leads to completely trivial DoS attacks (AFAICS, at least). Of course that's a lot better than trivial MITM, but it's still not exactly "good".
  - e12e 12y ago
    If you're in a position to MITM DoS is trivial anyway.
    - lomnakkus 12y ago
      I was primarily thinking against the CAs (or network paths to them), but yeah...
    - singlow 12y ago
      Backward. The dos would be possible for many to whom the mitm is impossible.
- rdl 12y ago
  I wish Cloudflare or Google would get into the CA game; they'd be more than capable of doing OCSP checks on every use, and could issue very short lived certificates otherwise (weekly?)
  - Nimi 12y ago
    Google appears to have gotten into the CA game with their Certificate Transparency initiative: http://www.certificate-transparency.org/ http://www.certificate-transparency.org/ As most of these Google initiatives go, this is open source, and they're encouraging other entities to adopt the technology.
- tptacek 12y ago
  Congratulations, you just broke every user accessing the Internet through a captive portal with an HTTPS login interface, and every user trying to access the Internet through crappy proxies. Which is one of the reasons why other browsers don't hard-fail on revocation checks.
  - claudius 12y ago
    And what exactly is the alternative? If any intermediate proxy/captive portal can say ‘oh, everything is fine’, how are we going to protect against MITM attacks?
    - tptacek 12y ago
      Out-of-band online CA checking is a weak design that doesn't work in practice. If revocation is required in a strict sense, then the solution will look something like "nuclear HSTS-style OCSP stapling". But to my mind, a simpler alternative would be for browsers to support something like TACK, so that instead of trying to knock down known-bad certificates, we just had a much better infrastructure for asserting which certificates are good. All that aside though, it's awfully silly to kick Google for noticing and pointing out this security problem with revocation checking. Other browsers are often literally pretending to do revocation checks that aren't actually meaningful.

by nialo 12y ago

claudius 12y ago

And the correct interpretation of ‘interrupted revocation check’ is ‘invalid certificate’. Now, of course there’s the problem that the CAs are apparently unable to provide constantly-running OCSP servers, making such an interruption more likely to be due to technical inadequacy of the CA than due to an ongoing MITM attack, but that is first and foremost a problem of the CAs, not of a browser vendor.

lomnakkus 12y ago
OTOH that just leads to completely trivial DoS attacks (AFAICS, at least). Of course that's a lot better than trivial MITM, but it's still not exactly "good".
- e12e 12y ago
  If you're in a position to MITM DoS is trivial anyway.
  - lomnakkus 12y ago
    I was primarily thinking against the CAs (or network paths to them), but yeah...
  - singlow 12y ago
    Backward. The dos would be possible for many to whom the mitm is impossible.
rdl 12y ago
I wish Cloudflare or Google would get into the CA game; they'd be more than capable of doing OCSP checks on every use, and could issue very short lived certificates otherwise (weekly?)
- Nimi 12y ago
  Google appears to have gotten into the CA game with their Certificate Transparency initiative: http://www.certificate-transparency.org/ http://www.certificate-transparency.org/ As most of these Google initiatives go, this is open source, and they're encouraging other entities to adopt the technology.
tptacek 12y ago
Congratulations, you just broke every user accessing the Internet through a captive portal with an HTTPS login interface, and every user trying to access the Internet through crappy proxies. Which is one of the reasons why other browsers don't hard-fail on revocation checks.
- claudius 12y ago
  And what exactly is the alternative? If any intermediate proxy/captive portal can say ‘oh, everything is fine’, how are we going to protect against MITM attacks?
  - tptacek 12y ago
    Out-of-band online CA checking is a weak design that doesn't work in practice. If revocation is required in a strict sense, then the solution will look something like "nuclear HSTS-style OCSP stapling". But to my mind, a simpler alternative would be for browsers to support something like TACK, so that instead of trying to knock down known-bad certificates, we just had a much better infrastructure for asserting which certificates are good. All that aside though, it's awfully silly to kick Google for noticing and pointing out this security problem with revocation checking. Other browsers are often literally pretending to do revocation checks that aren't actually meaningful.