4 ms·

WebPKI certificate revocation doesn't work anyways. It fails in exactly the case where TLS is needed: MITM. All certificate revocation-checking schemes "fail

WebPKI certificate revocation doesn't work anyways. It fails in exactly the case where TLS is needed: MITM. All certificate revocation-checking schemes "fail open" and proceed happily on their way if the MITM blocks their communications with the revocation lists. If you somehow don't have to worry about MITM you don't need anything remotely close to the complexity of TLS. Certificate revocation is mostly security theater.

vbezhenar 5y ago
That's issue with buggy clients which should not proceed if CRL is not available. Not issue with PKI per se.
- octoberfranklin 5y ago
  If they didn't fail open, every time a CA's website went down every single website that used their certificates would go offline as well. You can imagine the DDOS-ransomers licking their lips at this possibility. No, "fail open" has always been the only possible way to implement this. Which is why it's a broken idea from the start.
  - vbezhenar 5y ago
    > If they didn't fail open, every time a CA's website went down every single website that used their certificates would go offline as well. That's not correct. OCSP stamps exist to prevent that kind of a problem.
    - zauguin 5y ago
      OCSP always seemed a bit absurd to me: Instead of sending a OCSP stamp, the CA could also issue a very short lived certificate on demand. It would have the same effect of asserting that the CA currently considers the server to be verified and it doesn't need a separate format.
cmeacham98 5y ago
> All certificate revocation-checking schemes "fail open" and proceed happily on their way if the MITM blocks their communications with the revocation lists. Incorrect, firefox implements OCSP Must-Staple and treats a failure there as equivalent to a certificate validation failure. Now if only we could ever get chrome(ium) to implement it...
- octoberfranklin 5y ago
  OCSP Must-Staple is just another name for "really short certificate expiration periods" Must-Staple with a timeout of X seconds is functionally equivalent to a certificate with a validity time of X seconds. In either case you need to go fetch something from the CA every X seconds, or else get booted off the net. The only difference is what you call that thing. HN is doing its silly "slow down" nonsense, so I will reply to the reply below by editing here. To @cmeacham98: I'm not moving the goalposts; all practical revocation schemes fail open. OCSP Must-Staple isn't actually a form of revocation; it is just expiry with a fancy name and lots of extra complexity. The implementation quirks of one particular CA (LE) are not features of these protocols; they are features of that particular CA's policies. To @mhils: CAs could easily stand up simple servers that let you ask for the most recent certificate (if any) issued to a given domain and public key. They don't want to do this because it's a burden. The only reason they run OCSP servers is that they're under pressure from insurers, regulators, and auditors to participate in the whole revocation theater game. Saying "we don't do revocation" would cause people to freak out, and setting up an OCSP server takes effort, but less effort than explaining to the insurers/regulators/auditors that revocation doesn't actually work. As for CT, the log could simply include an extra (issuer-signed) field which amounts to "I will auto-renew this certificate until $DATE" and omit all the additional certificates issued to that same public key and domain name between the log entry and $DATE. Of course the browser would need to understand this field in order to validate the CT log entry. I'm not sure super-short expiration is really preferable; it makes the Web even more fragile than it already is. Frankly I think Web PKI is sort of a big mess at this point. Most of it only makes sense when viewed through the lens of "(a) governments will always control DNS for the the two-letter TLDs, (b) Google cannot get all governments to supplicate to Google, therefore (c) we must conjure up an extra layer of entities (the CAs) that can be bullied around by manipulation of browser engine code". This is basically the only reason why DANE (or a modernized revision of it) isn't used.
MattPalmer1086 5y ago
It limits the time in which a certificate compromise can be exploited. Clients cache CRLs. Without revocation, a compromised cert remains useful to an attacker for the entire validity period of the cert, it they can MITM you. With revocation, they must MITM you constantly to prevent you from acquiring the revocation list. This substantially adds to cost and complexity of such an attack, and means that many, if not all clients will be protected. So it's not perfect, but ask what the world looks like without it.

vbezhenar 5y ago

That's issue with buggy clients which should not proceed if CRL is not available. Not issue with PKI per se.

octoberfranklin 5y ago
If they didn't fail open, every time a CA's website went down every single website that used their certificates would go offline as well. You can imagine the DDOS-ransomers licking their lips at this possibility. No, "fail open" has always been the only possible way to implement this. Which is why it's a broken idea from the start.
- vbezhenar 5y ago
  > If they didn't fail open, every time a CA's website went down every single website that used their certificates would go offline as well. That's not correct. OCSP stamps exist to prevent that kind of a problem.
  - zauguin 5y ago
    OCSP always seemed a bit absurd to me: Instead of sending a OCSP stamp, the CA could also issue a very short lived certificate on demand. It would have the same effect of asserting that the CA currently considers the server to be verified and it doesn't need a separate format.

cmeacham98 5y ago

> All certificate revocation-checking schemes "fail open" and proceed happily on their way if the MITM blocks their communications with the revocation lists. Incorrect, firefox implements OCSP Must-Staple and treats a failure there as equivalent to a certificate validation failure. Now if only we could ever get chrome(ium) to implement it...

octoberfranklin 5y ago
OCSP Must-Staple is just another name for "really short certificate expiration periods" Must-Staple with a timeout of X seconds is functionally equivalent to a certificate with a validity time of X seconds. In either case you need to go fetch something from the CA every X seconds, or else get booted off the net. The only difference is what you call that thing. HN is doing its silly "slow down" nonsense, so I will reply to the reply below by editing here. To @cmeacham98: I'm not moving the goalposts; all practical revocation schemes fail open. OCSP Must-Staple isn't actually a form of revocation; it is just expiry with a fancy name and lots of extra complexity. The implementation quirks of one particular CA (LE) are not features of these protocols; they are features of that particular CA's policies. To @mhils: CAs could easily stand up simple servers that let you ask for the most recent certificate (if any) issued to a given domain and public key. They don't want to do this because it's a burden. The only reason they run OCSP servers is that they're under pressure from insurers, regulators, and auditors to participate in the whole revocation theater game. Saying "we don't do revocation" would cause people to freak out, and setting up an OCSP server takes effort, but less effort than explaining to the insurers/regulators/auditors that revocation doesn't actually work. As for CT, the log could simply include an extra (issuer-signed) field which amounts to "I will auto-renew this certificate until $DATE" and omit all the additional certificates issued to that same public key and domain name between the log entry and $DATE. Of course the browser would need to understand this field in order to validate the CT log entry. I'm not sure super-short expiration is really preferable; it makes the Web even more fragile than it already is. Frankly I think Web PKI is sort of a big mess at this point. Most of it only makes sense when viewed through the lens of "(a) governments will always control DNS for the the two-letter TLDs, (b) Google cannot get all governments to supplicate to Google, therefore (c) we must conjure up an extra layer of entities (the CAs) that can be bullied around by manipulation of browser engine code". This is basically the only reason why DANE (or a modernized revision of it) isn't used.

MattPalmer1086 5y ago

It limits the time in which a certificate compromise can be exploited. Clients cache CRLs. Without revocation, a compromised cert remains useful to an attacker for the entire validity period of the cert, it they can MITM you. With revocation, they must MITM you constantly to prevent you from acquiring the revocation list. This substantially adds to cost and complexity of such an attack, and means that many, if not all clients will be protected. So it's not perfect, but ask what the world looks like without it.