5 ms·

OCSP is a request/response protocol intended to answer certificate validity questions. It works as you describe, and failures cannot be treated as errors. An at

OCSP is a request/response protocol intended to answer certificate validity questions. It works as you describe, and failures cannot be treated as errors. An attacker who stole a certificate can use it even after revocation by blocking access the relevant OCSP responder. https://tools.ietf.org/html/rfc2560 https://tools.ietf.org/html/rfc2560 OCSP stapling is a mechanism by which a TLS server can make OCSP requests ahead of time and serve the response in-band. TLS clients get a certificate signed by the CA as usual, as well as a recent OCSP response signed by the CA attesting to its continued validity. OCSP stapling allows TLS clients like browsers to know a certificate's revocation status without having to make an extra request, but it changes nothing for an attacker who stole a certificate since they can simply not use it. https://tools.ietf.org/html/rfc6066#section-8 https://tools.ietf.org/html/rfc6066#section-8 OCSP Must Staple is an option that can be included on a certificate stating "I promise to use OCSP stapling". An attacker who stole a "must staple" certificate can either include an OCSP response indicating the certificate is revoked, or they can omit an OCSP response which the TLS client will treat as a hard error. https://tools.ietf.org/html/rfc7633 https://tools.ietf.org/html/rfc7633 In short, RFC 7633 makes certificate revocation work. Web browsers and web servers support this today. If you use Let's Encrypt's `certbot`, pass it `--must-staple`.

tialaramex 7y ago
If you have Must Staple but don't have monitoring in place to detect that your OCSP responses are growing stale before they expire (or worse, you use Apache HTTPD which will happily replace a GOOD OCSP response with a newer BAD one) then you'd still be screwed here when Let's Encrypt revokes certificates. You need at least effective monitoring and a good OCSP stapling implementation (IIS is supposedly pretty good at this) or else stapling is sadly going to make life worse for you not better.
wbond 7y ago
So in the case that revocation now works, why is there a continued push to shorten certificate lifetimes?
- pfg 7y ago
  Multiple reasons: 1. Firefox remains the only mainstream browser to support OCSP Must Staple. 2. OCSP Must Staple does not cover all threat models: if an attacker gains the ability to temporarily issue certificates for the victim's domain (rather than obtaining the private key of an existing certificate), they can request a certificate without the OCSP Must Staple extension. A more effective method would be something like the Expect-Staple header[1] (in enforce mode). 3. It allows the ecosystem to move significantly faster. In a world where all certificates expire after 3 months, phasing out insecure hash algorithms (in certificates) would no longer take many years. 4. It encourages regular key rotation (even if it's not enforced) [1]: https://scotthelme.co.uk/designing-a-new-security-header-expect-staple/ https://scotthelme.co.uk/designing-a-new-security-header-exp...
  - wbond 7y ago
    Items 3 and 4 seem like weak arguments. We are still dealing with operating systems from 3+ years ago, so moving below a 1 year certificate length wouldn't buy much agility in terms of new algorithms.
    - pfg 7y ago
      Hash algorithms may not have been the best examples as they require client support. A better example would be something like Certificate Transparency. Currently, browsers may require Certificate Transparency for certificates issued after a certain date. A malicious or compromised CA may work around this by backdating certificates. This would be less of an issue with shorter certificate lifetimes.

tialaramex 7y ago

If you have Must Staple but don't have monitoring in place to detect that your OCSP responses are growing stale before they expire (or worse, you use Apache HTTPD which will happily replace a GOOD OCSP response with a newer BAD one) then you'd still be screwed here when Let's Encrypt revokes certificates. You need at least effective monitoring and a good OCSP stapling implementation (IIS is supposedly pretty good at this) or else stapling is sadly going to make life worse for you not better.

wbond 7y ago

So in the case that revocation now works, why is there a continued push to shorten certificate lifetimes?

pfg 7y ago
Multiple reasons: 1. Firefox remains the only mainstream browser to support OCSP Must Staple. 2. OCSP Must Staple does not cover all threat models: if an attacker gains the ability to temporarily issue certificates for the victim's domain (rather than obtaining the private key of an existing certificate), they can request a certificate without the OCSP Must Staple extension. A more effective method would be something like the Expect-Staple header[1] (in enforce mode). 3. It allows the ecosystem to move significantly faster. In a world where all certificates expire after 3 months, phasing out insecure hash algorithms (in certificates) would no longer take many years. 4. It encourages regular key rotation (even if it's not enforced) [1]: https://scotthelme.co.uk/designing-a-new-security-header-expect-staple/ https://scotthelme.co.uk/designing-a-new-security-header-exp...
- wbond 7y ago
  Items 3 and 4 seem like weak arguments. We are still dealing with operating systems from 3+ years ago, so moving below a 1 year certificate length wouldn't buy much agility in terms of new algorithms.
  - pfg 7y ago
    Hash algorithms may not have been the best examples as they require client support. A better example would be something like Certificate Transparency. Currently, browsers may require Certificate Transparency for certificates issued after a certain date. A malicious or compromised CA may work around this by backdating certificates. This would be less of an issue with shorter certificate lifetimes.