Revoking an OCSP Responder

There is a pretty large flaw with the OCSP protocol: you cannot revoke an OCSP responder certificate.

Or to be more precise, you can revoke an OCSP responder certificate, but applications will never check this.

Consider the process of validating a certificate using OCSP:

  1. Machine receives certificate from a Web Server.
  • Machine builds a trust chain for the certificate, leading to a trusted CA certificate.
  • Machine finds the OCSP responder in the AIA extension for each of the CA certs in the trust chain (except the root).
  • Machine asks the OCSP responder(s) if the issued certificate(s) is valid.
  • OCSP responder provides a yes/no/i don’t know response.
  • Machine checks to see if the OCSP responder’s signing certificate is trusted to be able to trust the response given.

Right there at the end of that process, the OCSP responder’s signing certificate is checked for trust, but not for revocation.

And if it did check for revocation, then that would break the purpose of this whole technology, as it would need to check a CRL in the process. And the end game here is that we’re trying to avoid checking CRLs here by using OCSP.

So ideally, an attacker should aim their sights towards either obtaining an existing OCSP responder signing certificate, or generating one that is trusted in some manner (through hash collisions or exploitation of business process). Once they have that certificate, then they have the ability to feign validity for other compromised certificates up until the end of the responder certificate validity period.

(and if they compromised it once, there’s a good chance they can do it again)

Mitigating this risk?

So we know that we can’t do a whole lot about this problem. The only thing we can do is mitigate risk. Here are some mitigation strategies:

  • Store the OCSP response signing keys inside a Hardware Security Module. This will prevent the private key ever leaving your control (assuming the HSM doesn’t also get compromised…).
  • Restrict access to the OCSP responder from managed networks only (this only works if you don’t need it internet facing).
  • Harden the OCSP management interface with Multifactor Authentication.
  • Reduce the lifetime of the OCSP response signing keys to a very short time period (30 days or so).

There is significant residual risk though even after mitigation. Even having a certificate that’s 30 days long still provides a 30 day window for attack if somebody managed to compromise it on day zero.

The only real solution I can see being viable for now is to revoke the issuing Certificate Authority of a potentially compromised OCSP responder, and if you have a lot of dependant systems on this Certificate Authority this could be a nightmare. It would be nice to be able to segregate the OCSP signing certificates to be under their own Certificate Authority, but unfortunately for the protocol to work the responder will require keys for OCSP signing under each issuing Certificate Authority that it has to respond for.

In conclusion, be extremely careful in how you implement OCSP in your organisation.