Comment by willglynn | Hacker News Reader

Comment by willglynn | Hacker News Reader

Parent Full thread

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

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

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

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

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.

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

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

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.

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.

Reply on news.ycombinator.com