3 ms·

Meanwhile Chrome doesn't even support OCSP (Certificate Revocation) for performance reasons, not even after Heartbleed. I hope that doesn't sound like fanboyis

by tete 12y ago

Meanwhile Chrome doesn't even support OCSP (Certificate Revocation) for performance reasons, not even after Heartbleed. I hope that doesn't sound like fanboyism, but not being able to communicate a certificate revocation properly is worrisome.

tptacek 12y ago
That's because OCSP doesn't work. The real-world Internet routinely breaks OCSP queries, which results in Firefox (and other browsers) soft-failing them: if OCSP doesn't work, the browser goes ahead with the connection. The security problem here is trivially observed. TLS certificate revocation is a mess. We know what the solution will look like: it'll be something like HSTS, except that instead of caching "this site must use HTTPS", we'll also cache "this site must use OCSP stapling", and the OCSP data will be conveyed in-band in the HTTPS connection. It's hard to ding Chrome for not supporting something that doesn't really exist yet. So, no: not "for performance reasons". Incidentally: Chrome more or less invented certificate pinning.
- tete 12y ago
  But OCSP is the only thing that's widely supported as of now. You can't on one hand say "don't blame Chrome to not support something that doesn't exist", when at the same time it rejects something that's widely deployed and even is considered a requirement for CAs. Being able to revoke your certificate, even if it has problems is better than not being able to. OCSP is still the standard way of communicating certificate revocations and even with all the HTTP-Extensions you need a way for certificate revocation. Unlike most alternatives OCSP is out of the box supported by IE, Firefox, Opera and Safari. Only Chrome has it disabled per default. Most people revoked their old certificates after Heartbleed. This is an example of where you need an alternative to just pinning a key. So you are saying that an attacker has to make sure that the OCSP connection isn't working means OCSP is worse than having no possibility of certificate revocation at all? Not saying that it's absolutely secure. Hopefully everyone knows that there are flaws in HTTPS/SSL. Zooko's triangle[1] even gives you a hint why. Also I am curious. What better, more widely used way of Certificate Revocation do you know? [1] https://en.wikipedia.org/wiki/Zooko%27s_triangle https://en.wikipedia.org/wiki/Zooko%27s_triangle
  - deleted 12y ago
    [deleted]
  - danudey 12y ago
    OSCP fails often enough that requiring a verified pass would break the internet. Thus, browsers which support OSCP treat a failure to fetch OSCP data as a soft fail (i.e. they ignore it). The problem is that if you can MITM someone, you can deny them access to the OSCP service and cause a soft fail, which makes OSCP worthless.
    - Pxtl 12y ago
      Just because it doesn't stop a full MITM between the CA and the client doesn't make it worthless. It still protects the user from trusting a server that is no longer trustworthy. If a certificate is worth issuing when a server is trustworthy, it's worth revoking when the server loses that trust.
      - tptacek 12y ago
        We are talking about adversaries who control both secrets and connectivity. Not because those are the adversaries we care most about, but because those are the adversaries that key revocation contemplates. The notion of "full MITM" versus "partial MITM" versus "passive-only" attacker does not apply.
- Pxtl 12y ago
  OCSP is still useful, it's just not panacea. Getting timely notification that cert A is invalid or that server B should no longer be using cert A is still good. It doesn't solve every problem (like somebody blocking access to the CA to prevent the OCSP check) but it's not worthless. It can be defeated if the user or his ISP is pwned. It might kick in too late to properly save the user if the connection to the CA is too slow. But it still does nicely handle the case where a server and its cert are no longer trustworthy.
  - tptacek 12y ago
    OCSP mitigates attacks by adversaries who control cryptographic secrets and connectivity (or else those secrets don't do any good). It's defeated trivially by manipulating connectivity just enough to break OCSP. It's not useful at all. This is a common pathology when thinking about security. Lots of things appear to work when they aren't being tested by a real attacker, but don't work at all when they are. It's like an insurance policy that you pay small premiums to that then vanishes when a disaster strikes. Like I said upthread: there's a way to make something like OCSP work: the OCSP signaling can be moved in-band, so it can't be attacked separately from the TLS session itself, and then made sticky through an HSTS-like mechanism. But until OCSP gets a "Must-Staple" mechanism, it provides literally no real benefit.
    - Pxtl 12y ago
      Obviously stapling improves on OCSP, and OCSP is flawed. But OCSP is better than nothing. It's not 100% useless - if a server or a cert has been owned, OCSP will protect the user from that. If the user has been owned, only stapling will save them, so obviously a move towards stapling is a good idea. But don't let the perfect be the enemy of the "better than nothing".
eplsaft 12y ago
Revocation in this case of pinned key means setting the max-age to 0 of the previous key and pinning a new key. This must be done before attacker is able to MITM.

by tete 12y ago

tptacek 12y ago

That's because OCSP doesn't work. The real-world Internet routinely breaks OCSP queries, which results in Firefox (and other browsers) soft-failing them: if OCSP doesn't work, the browser goes ahead with the connection. The security problem here is trivially observed. TLS certificate revocation is a mess. We know what the solution will look like: it'll be something like HSTS, except that instead of caching "this site must use HTTPS", we'll also cache "this site must use OCSP stapling", and the OCSP data will be conveyed in-band in the HTTPS connection. It's hard to ding Chrome for not supporting something that doesn't really exist yet. So, no: not "for performance reasons". Incidentally: Chrome more or less invented certificate pinning.

tete 12y ago
But OCSP is the only thing that's widely supported as of now. You can't on one hand say "don't blame Chrome to not support something that doesn't exist", when at the same time it rejects something that's widely deployed and even is considered a requirement for CAs. Being able to revoke your certificate, even if it has problems is better than not being able to. OCSP is still the standard way of communicating certificate revocations and even with all the HTTP-Extensions you need a way for certificate revocation. Unlike most alternatives OCSP is out of the box supported by IE, Firefox, Opera and Safari. Only Chrome has it disabled per default. Most people revoked their old certificates after Heartbleed. This is an example of where you need an alternative to just pinning a key. So you are saying that an attacker has to make sure that the OCSP connection isn't working means OCSP is worse than having no possibility of certificate revocation at all? Not saying that it's absolutely secure. Hopefully everyone knows that there are flaws in HTTPS/SSL. Zooko's triangle[1] even gives you a hint why. Also I am curious. What better, more widely used way of Certificate Revocation do you know? [1] https://en.wikipedia.org/wiki/Zooko%27s_triangle https://en.wikipedia.org/wiki/Zooko%27s_triangle
- deleted 12y ago
  [deleted]
- danudey 12y ago
  OSCP fails often enough that requiring a verified pass would break the internet. Thus, browsers which support OSCP treat a failure to fetch OSCP data as a soft fail (i.e. they ignore it). The problem is that if you can MITM someone, you can deny them access to the OSCP service and cause a soft fail, which makes OSCP worthless.
  - Pxtl 12y ago
    Just because it doesn't stop a full MITM between the CA and the client doesn't make it worthless. It still protects the user from trusting a server that is no longer trustworthy. If a certificate is worth issuing when a server is trustworthy, it's worth revoking when the server loses that trust.
    - tptacek 12y ago
      We are talking about adversaries who control both secrets and connectivity. Not because those are the adversaries we care most about, but because those are the adversaries that key revocation contemplates. The notion of "full MITM" versus "partial MITM" versus "passive-only" attacker does not apply.
Pxtl 12y ago
OCSP is still useful, it's just not panacea. Getting timely notification that cert A is invalid or that server B should no longer be using cert A is still good. It doesn't solve every problem (like somebody blocking access to the CA to prevent the OCSP check) but it's not worthless. It can be defeated if the user or his ISP is pwned. It might kick in too late to properly save the user if the connection to the CA is too slow. But it still does nicely handle the case where a server and its cert are no longer trustworthy.
- tptacek 12y ago
  OCSP mitigates attacks by adversaries who control cryptographic secrets and connectivity (or else those secrets don't do any good). It's defeated trivially by manipulating connectivity just enough to break OCSP. It's not useful at all. This is a common pathology when thinking about security. Lots of things appear to work when they aren't being tested by a real attacker, but don't work at all when they are. It's like an insurance policy that you pay small premiums to that then vanishes when a disaster strikes. Like I said upthread: there's a way to make something like OCSP work: the OCSP signaling can be moved in-band, so it can't be attacked separately from the TLS session itself, and then made sticky through an HSTS-like mechanism. But until OCSP gets a "Must-Staple" mechanism, it provides literally no real benefit.
  - Pxtl 12y ago
    Obviously stapling improves on OCSP, and OCSP is flawed. But OCSP is better than nothing. It's not 100% useless - if a server or a cert has been owned, OCSP will protect the user from that. If the user has been owned, only stapling will save them, so obviously a move towards stapling is a good idea. But don't let the perfect be the enemy of the "better than nothing".

eplsaft 12y ago

Revocation in this case of pinned key means setting the max-age to 0 of the previous key and pinning a new key. This must be done before attacker is able to MITM.