Transport Layer Security (TLS), the authentication and encryption protocol for HTTPS, relies on certificates to bind servers’ identities to their public keys.
Inevitably, these public and private keys are sometimes compromised and, as a consequence, certificates are misissued. In such cases, the owner of a certificate must ask the Certificate Authority (CA) who issued the certificate to revoke it.
The CA then revokes the certificate by producing a public attestation that the certificate should not be trusted and the CA is responsible for disseminating such attestations for all revoked certificates that they have issued.
There are two primary protocols by which clients (for example, browsers) communicate with CAs to obtain revocation attestations: Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP).
CRLs vs OCSP
CRLs are simply a list of all revoked certificates for a CA. CAs include a URL in a certificate as an extension so that a client can locate the CRL and download the list to check the revocation status of the certificate.
Once a client has a fresh copy of a certificate’s CRL, the client can quickly determine whether the certificate is revoked by checking if the certificate is in the CRL. However, CRLs are often criticized due to their inefficiency: a client needs to download all certificate revocation information — the CRL contains all revoked certificates that the CA has revoked — even though it is only interested in a single certificate.
OCSP is a web service protocol that allows a client to query the CA for the revocation status of a single certificate. The CA runs a server called OCSP Responder so that the client can query the server by locating the URL in a certificate, which reduces the overhead of CRLs.
OCSP, however, has multiple issues; first, because clients depend on the OCSP response, the OCSP responders need to provide responses with low latency and high availability; second, the CAs can observe users’ browsing behaviour by monitoring incoming OCSP requests from the clients.
OCSP Stapling
OCSP Stapling was introduced to address these two problems. The web server obtains an OCSP response ahead of time from the CA and then it provides the certificate, along with this stapled OCSP response, to the client during the TLS handshake. As a result, the client receives both the certificate with its OCSP response at the same time without any additional requests to the CA.
Unfortunately, OCSP Stapling does not solve all issues with OCSP. The biggest problem is that most clients will accept a certificate even if they are unable to obtain OCSP responses; this behaviour is called ‘soft-failure’ (as opposed to ‘hard-failure’, where the client rejects the certificate if it cannot obtain revocation information).
This behaviour may be partially beneficial when OCSP responders are temporarily unavailable or web servers happen to forget to provide the stapled OCSP response. However, an attacker can exploit this behaviour by blocking the OCSP request from the client or stripping any stapled OCSP responses to make the client accept a revoked certificate.
OCSP Must-Staple
OCSP Must-Staple aims to solve the problem of soft-failure: it is an X.509 certificate extension, which tells a client to expect an OCSP response to be provided (stapled) by the web server whenever it sees the extension in the certificate. If the extension is included in the certificate, it acts as an explicit signal to the client that it must hard-fail if the server does not provide a fresh, valid OCSP response in the TLS handshake.
Importantly, OCSP Must-Staple does not introduce any additional latency and CAs cannot track the clients’ browsing behaviour. It also solves the soft-failure problem of the clients.
So, is the web ready for OCSP Must-Staple?
In order for OCSP Must-Staple to be deployed successfully, each of the three major entities in the Public Key Infrastructure — CAs, clients (browsers), and web server — needs to perform its role correctly.
As such, we at the Rochester Institute of Technology in collaboration with Northeastern University, University of Maryland, Duke University, Max Planck Institute, Akamai Technologies, and Cloudflare, conducted a preliminary study prior to the release of OCSP Must-Staple to validate the current productivity and effectiveness of these entities; the results of which I’ll elaborate on in my next two posts, including recommendations as to what action these entities need to take before OCSP Must-Staple can be effective.
Read:
- Part 2 — Incorporating OCSP Must-Staple into certificates
- Part 3 — Is the web ready for OCSP Must-Staple?
Taejoong (Tijay) Chung is an Assistant Professor at Rochester Institute of Technology (RIT).
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
Postfix currently lacks the ability to staple OCSP responses, so a certificate with the Must-Staple extension cannot be shared.
We get Tls certificates. Then TLS certs need to be checked. So you need a certification for the certificate…
See where it leads ?
Where it leads?
DNSSEC + DANE.
Can use self-signed certificates and doesn’t require OCSP.