OCSP Must-Staple is a certificate extension that was introduced to address the slow performance, unreliability, soft-failures, and privacy issues associated with Online Certificate Status Protocol (OCSP).
In order for it to be deployed successfully, each of the three major entities in the Public Key Infrastructure (PKI) — CAs, clients (browsers), and web servers — needs to perform its role reliably and correctly.
In my previous post, I discussed what improvements Certificate Authorities (CAs) needed to make for it to be effectively deployed, so will now turn my attention to clients and web servers, as well as providing our conclusive remarks on whether the web is indeed ready to take advantage of the benefits of OCSP Must-Staple.
- Part 1 — Overcoming the limitations of OCSP
- Part 2 — Incorporating OCSP Must-Staple into certificates
How many clients/browsers solicit stapled OCSP responses?
To see how many popular TLS clients — web browsers — support OCSP Must-Staple correctly, we purchased a domain name, deployed a valid certificate with the Must-Staple extension and ran the web server to serve the certificate. However, we deliberately did not provide any stapled OCSP responses to check if clients reject this certificate or not.
We then tried to connect to our test domain using a variety of popular web browsers (Chrome, Firefox, Opera, Safari, Internet Explorer, and Microsoft Edge on desktop OSes (OS X, Linux, Windows) and mobile OSes (iOS and Android). The results of this experiment are summarized in Table 1.
Table 1 — Browser test results: all of the desktop and mobile browsers request OCSP responses in the SSL/TLS handshake (indicated as ✓); however, most of the browsers, except the Firefox on Android and across three desktop OSes, show warnings or terminate the connection even though they do not receive an OCSP response with an OCSP Must-Staple certificate (indicated as ✗). Also none of those browsers who accept the certificate make own OCSP request to the OCSP responder.
We first observed that all browsers do solicit stapled OCSP responses, indicating that they do support OCSP Stapling. However, we observed that only Firefox (on all desktops OSes and on Android) displays a certificate error to the user if a stapled OCSP response is not included with a certificate that includes the OCSP Must-Staple extension; all other browsers (including Firefox on iOS) simply accept the certificate and do not even send their own OCSP request to the OCSP responder.
These results indicate that clients are largely not yet ready for OCSP Must-Staple. However, it does appear that all clients already support OCSP Stapling, meaning the additional coding work necessary to support OCSP Must-Staple is likely not too significant.
How well do Apache and Nginx support OCSP Stapling?
To support OCSP Must-Staple correctly, web server software such as Apache and Nginx must fully and correctly support OCSP Stapling, properly fetching and caching OCSP responses as well as handling errors when communicating with OCSP responders.
Similar to the experiment above, we tested well-known web servers (Apache and Nginx) to see how well they correctly support OCSP Must-Staple in three different perspectives:
- Performance: First, we see if web server software proactively fetches OCSP responses. If web servers do not—and instead fetch OCSP responses on-demand—this could either introduce unnecessary latency in completing the TLS handshake, or cause the web server to not include an OCSP response when responding to the first (few) client(s).
- Caching: Second, web servers should cache OCSP responses for efficiency. However, web servers should respect the expiration time of OCSP responses, and remove them from the cache once they have expired.
- Availability: Third, when fetching an updated OCSP response, web servers may encounter an OCSP responder that is unavailable or returns an error. In such cases, the web server should retain the existing cached OCSP response until it expires (while periodically retrying with the OCSP responder).
| Experiment | Apache | Nginx |
| Prefetch OCSP response | ✗ (pause connection) | ✗ (provide no response) |
| Cache OCSP response | ✓ | ✓ |
| Respect expiration in cache | ✗ | ✓ |
| Retain OCSP response on error | ✗ | ✓ |
The first observation we made was that both Apache or Nginx do not prefetch the OCSP responses even though they serve certificates with the Must-Staple extension. Instead, they fetch an OCSP response when they receive the first incoming connection that uses a given certificate.
However, their behaviour differs with how they respond to this first client: Apache ‘pauses’ the TLS handshake until the OCSP response comes in, while Nginx simply does not provide an OCSP stapled response to the first client.
The second observation we made was that Apache does not respect the expiration time of the OCSP response and will continue to serve OCSP responses from the cache even after they expire.
The third and final observation was that when the web server encounters an error communicating with the OCSP responder (unavailability or an error response), Apache also deletes the old (still valid) OCSP response and either provides no OCSP response (if the OCSP responder is unavailable) or serves the error response itself (if the OCSP responder returns an error). In contrast, Nginx retains the old OCSP response and keeps providing it to clients until it expires.
In summary, both well-known web servers do not fully support OCSP Must-Staple correctly. We believe these undesirable behaviours of web servers could become a serious challenge for web administrators who choose to serve certificates with the OCSP Must-Staple extension: the clients that correctly support the extension might not be able to connect to their domains intermittently due to the above issues.
So, is the web ready for OCSP Must-Staple?
Our goal in this study was to shed light on if today’s web is ready for OCSP Must-Staple by measuring three major principles — OCSP responders, clients (browsers), and web servers — to see if what they are doing correctly support OCSP Must-Staple.
We observed that:
- 36.8% of OCSP responders experienced at least one outage, which typically lasted a few hours.
- All major browsers other than Firefox do not bother to ensure that stapled OCSP responses are actually included (stapled).
- Neither of the Apache and Nginx web servers prefetch an OCSP response, which introduces unnecessary latency in completing the TLS handshake with clients.
Considering OCSP Must-Staple can operate only if each of the principals in the PKI performs correctly, we conclude that, currently, the web is not ready for OCSP Must-Staple.
This work was done in collaboration with colleagues from Northeastern University, the University of Maryland, Duke University, Max Planck Institute, Akamai Technologies, and Cloudflare and presented at IMC’18.
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.
Also note that Nginx does not cache the responses between reloads and handles responses per server block, rather than per certificate, resulting in being rate-limited by Let’s Encrypt. Must staple is completely broken with these limitations.
https://trac.nginx.org/nginx/ticket/812
https://trac.nginx.org/nginx/ticket/1830
This article is over a year old. How has the situation changed in for now, December 2020?