OCSP Stapling: The Good, the Bad, and the Ugly

Encrypted communication is one of the most critical components for a secure internet. For instance, anyone wishing to connect securely to their online banking portal requires digital certificates. These are typically issued by a central authority and serve to prove the authenticity of websites and other services.

Allowing Only Valid Certificates

For certificates to be valid, they must meet specific cryptographic requirements. Additionally, certificates always have a fixed validity period: they are not valid before or after a certain point in time, which helps protect certificates from misuse.

In the past, it was not uncommon for certificates to be valid for five years or more, and naturally, some of these were compromised by hackers during that time. The attackers could then impersonate the service from which the certificate was stolen until the validity period expired. This need to keep the timeframe as short as possible was one of the reasons why leading browser vendors recently limited the validity period to 398 days. The certificate authority Let’s Encrypt has gone a step further, issuing certificates with a maximum validity of 90 days and even recommending shortening them to 60 days.

Real-Time Validity Verification

However, these timeframes are of little help if it is discovered that something is wrong with the server and the certificate may have fallen into the hands of a hacker: it must be declared invalid, as quickly and immediately as possible!

Aside from relatively cumbersome Certificate Revocation Lists (CRLs), which never achieved widespread adoption on the internet, there is a method to query the validity of certificates from a validation service: the Online Certificate Status Protocol (OCSP).

During certificate validation via the Online Certificate Status Protocol, the web browser sends a request (OCSP Request) to the certificate authority's validation service, also known as the OCSP Responder, when accessing a website. This validation service returns a response (OCSP Response) to the web browser. Once the web browser has received the OCSP response, it can verify the validity status of the certificate in near real-time and reject the certificate if it is invalid.

As is often the case, this mechanism has a downside: privacy issues can arise if unencrypted OCSP requests are intercepted. This recently forced tech giant Apple to clarify its data usage after renewed criticism that operating system vendors or internet service providers could create precise personal profiles based on partially unencrypted usage data. The same applies, of course, to the validation service, which receives all OCSP requests.

Similarly, accessing websites can result in longer loading times, as an additional OCSP query must be performed. If the validation service fails, the connection may not be established at all.

Dependency on a Second Service

If an attacker blocks the OCSP communication and the browser subsequently receives no response, the website is still loaded without displaying a warning message. This behavior is known as a Soft Fail, which is intended to prevent the failure of the validation service from also causing the failure of the website.

A process based on the Hard Fail principle would block the connection setup and inform the user with a warning message about an unsuccessful OCSP validation. However, so far, only the Mozilla Firefox browser has integrated such a warning message, which also blocks the connection.

All Chromium-based web browsers (Chrome, Opera, Edge, Vivaldi, etc.) forgo a warning message and rely on the use of CRLSets instead of OCSP. In doing so, they aim to maintain user-friendliness and avoid overwhelming internet users with a warning message they might not understand. However, with CRLSets, one encounters the typical problems of Certificate Revocation Lists: size limitations, cumbersomeness, and timeliness limited by versions.

Taking a Detour to Reach the Goal: OCSP Stapling

Instead of the browser making an OCSP request, this task is now taken over by the web server. The web server itself makes an OCSP request at regular intervals and transmits the response to the browser during the connection setup. The response is essentially "stapled" to the connection setup, which is where the name OCSP Stapling comes from. Initially, the implementations of web servers such as Nginx or Apache for stapling were bug-prone, but this situation has improved significantly, and with mod_md in current Apache versions, there is now a simple way to activate OCSP Stapling for all delivered certificates.

Stapling solves the privacy problem created by the additional OCSP request, as this is now carried out by the web server. Similarly, connection speed is improved by eliminating the query, and validation services are relieved. Due to the included signature from the certificate authority and the short lifespan of the OCSP response, it can be trusted even though it is not sent directly from the OCSP Responder, but from the web server to which the actual website request is being made.

Theoretically, it is no longer possible to block OCSP communication through stapling. However, an attacker in possession of a stolen server certificate, acting as a malicious service provider, would not offer OCSP Stapling. The browser would establish the encrypted connection and then attempt to perform an OCSP request. The attacker could block this request again and deceive the user with a certificate that has already been revoked.

To prevent such downgrade attacks, an extension for X.509 certificates, Must-Staple, was designed. Using this extension, the certificate communicates that the service provider must offer OCSP Stapling. For the Must-Staple extension to be used, browser vendors must implement this certificate extension, which has not yet been done by all. The browser would receive the Must-Staple information from the certificate and subsequently expect an OCSP response during the connection setup. If it does not receive this response, it must enter a Hard Fail state and fail the connection.

With this extension, only connections that provide valid stapled OCSP information during the connection setup are established.
It can still happen that an attacker succeeds in stealing a certificate, the associated key, and a valid OCSP response. In the worst case, while the certificate would be revoked by the actual service provider, the attacker could still use the certificate during the usual seven-day validity period of the OCSP response, despite Must-Staple. With the next update of the OCSP response, at the latest after seven days, the certificate would finally be declared invalid.

Conclusion: More Good than Bad, but Sometimes Ugly

The Online Certificate Status Protocol (OCSP) is used to verify the validity of certificates in real-time. This provides browsers with a tool to detect the invalidity of revoked certificates. However, only OCSP Stapling in combination with the Must-Staple certificate extension resolves significant weaknesses and ensures a robust process. Although this is not new, there is still a partial lack of support from web server or browser vendors; however, this has improved significantly recently.

aramido will soon present a solution for OCSP Stapling with HAProxy in this blog.