Internet security often becomes a delicate dance of safety, functionality, and user experience. A prime example is the ongoing struggle to connect browsers with information furnished by CAs regarding revoked certificates. This FAQ defines the primary mechanisms that have been used for this purpose over time, including CRLs, OCSP, OCSP Stapling and Must-Staple, and, most recently, CRLite.
The initial attempt for CAs to publish the revocation status of their issued certificates was through certificate revocation lists (CRLs). A CRL is simply a list of all the certificates the CA has ever revoked before their scheduled expiration. These are periodically updated by the CAs, and browsers were required to review them before each HTTPS connection. Over time, the CRLs grew in size, as did the task of each browser reviewing them. As the time required to download and parse a large (and growing) CRL grew, so did delays for the user. In an effort to mitigate these issues, browsers and CAs developed and implemented the Online Certificate Status Protocol (OCSP).
The Online Certificate Status Protocol (OCSP) is the Internet protocol used by web browsers to determine the revocation status of SSL/TLS certificates supplied by HTTPS websites. While SSL/TLS certificates are always issued with an expiration date, there are certain circumstances in which a certificate must be revoked before it expires (for example, if its associated private key may have been compromised). Therefore, the current validity of a website’s certificate must always be checked by clients regardless of its expiry date.
In its simplest form, OCSP works as follows:
1. A web browser receives a certificate from an HTTPS website.
2. The web browser sends a request to an OCSP responder, a server operated by the certificate authority (CA) that issued the certificate.
3. The OCSP responder’s signed response to the browser indicates whether the certificate is valid or has been revoked.
Unfortunately, OCSP came with a number of issues. Many OCSP implementations weren’t reliable enough, which pushed impatient browsers and other client software to implement OCSP checking in soft-fail mode. This means that if an OCSP server couldn’t be reached in time while responding, the certificate would be considered valid and they would proceed with the HTTPS connection.
Man-in-the-middle attacks have exploited this by blocking all OCSP queries or connections, using a stolen certificate to gain access to a trusted HTTPS connection. This could result in sensitive information being shared with bad actors, which led to OCSP Stapling as a solution.
While initially introduced to solve the bandwidth and scaling problems of certificate revocation lists (CRLs), OCSP introduced several performance and security issues of its own that are currently being addressed through OCSP stapling. In OCSP stapling:
1. A web server requests and obtains a signed OCSP response for its certificate from an OCSP responder, which can be cached for up to 7 days.
2. The server includes the cached OCSP response along with (or “stapled to”) its certificate in its HTTPS responses to web browsers.
3. To prevent a potential attack in which a website serves a stolen revoked certificate without a stapled OCSP response, certificates may be issued with a must-staple extension, mandating OCSP stapling for the certificate.
Motivated by malicious moves by MITM attackers, CAs and browser vendors introduced an extension for SSL certificates known as OCSP Must-Staple (defined in RFC 7633, though not referred to there as “OCSP Must-Staple”).
OCSP Must-Staple requires OCSP Stapling for the certificate. If a browser comes into contact with a certificate without OCSP Stapling, it will be rejected. Not only does Must-Staple mitigate the threat of downgrade attacks, it also reduces unnecessary traffic to the CA’s OCSP responders, improving responsiveness and overall OCSP performance.
CRLite is a newly-proposed standard that would send information about ALL revoked SSL/TLS certificates directly to the browsers. This would potentially cut out all burdensome processes and unreliable connections between browsers and CAs by integrating the information about revoked CAs directly into the browsers.
A main concern may be the sheer amount of info being stored, seeing how the large and growing size of CRLs was and is one of the core issues with OCSP processes. CRLite uses bloom filters to compress large quantities of data, making them more manageable for the browsers.
If a certificate is too new, meaning not yet included in any updates, the browser would then use OCSP (stapled or actively queried).
