Introduction
When a user visits your HTTPS web site, it must respond with a working public key, and a valid SSL certificate associating the key with your identity, either as a person, company or organization. Certificates are always issued with a predefined expiration date that is included in the signed certificate itself, and browsers always check the expiry date and will reject any expired certificate.
However, in certain cases, a certificate must be marked as invalid (and trust at those certificates must be revoked) before it expires. Common examples include a server owner having evidence (or simply suspecting) that their private key was compromised (i.e. it was lost, stolen or destroyed), since a third party holding this private key can essentially bypass all browser network security controls.
As a consequence, browser vendors required publicly trusted certificate authorities (CAs) to implement at least one method to both revoke problematic certificates and to notify browsers to reject these revoked certificates.
A brief history of (the problems of) revocation checking
In the early days of SSL, the method CAs used was to publish their certificate revocation status in publicly accessible documents called certificate revocation lists (CRL). A CRL is simply a list of all the certificates that a CA has ever revoked before expiration. CAs periodically published the latest version of their CRLs, which browsers were required to consult with before each HTTPS connection.
Naturally, as HTTPS (and SSL/TLS) adoption increased over the years, so did the size of the published CRLs. The requirement of having to download and parse a large CRL before each connection imposed an ever-increasing network overhead. It quickly became apparent that the CRL method did not scale well.
To mitigate these scaling issues, browsers and CAs designed and implemented the Online Certificate Status Protocol (OCSP). Publicly trusted CAs, such as SSL.com, now maintain simple HTTP servers called OCSP responders. Browsers could now contact a responder to request the revocation status of a single certificate issued by the CA, instead of having to acquire and process the whole CRL.
OCSP responders sign their responses with the CA’s private signing key, and browsers can verify that the revocation status they received was indeed generated by the actual CA.
Unfortunately, even though OCSP seemed like an effective solution at first, the new protocol has proven to have some practical performance, security and privacy issues.
Performance issues
Contacting a responder for every certificate the browser encounters, means that browsers need to perform an additional HTTP request for each new HTTPS connection. This network overhead was perceptible to users, especially in pages containing third-party content stored in remote content-distribution servers (which each might have one or more certificates in place).
Responsiveness is an essential principle of good user interface design. Long delays can be a major cause of user frustration, and can lead users to believe your web site is not functioning or that their input gesture has been ignored.
What’s more, many studies in the past have linked fast page load speed and responsiveness with improved SEO and increased conversion rates. In fact, Amazon has calculated that a delay of just one second can cost them about $1.6 billion yearly.
(For more details on how page load speed affects your web site and suggested optimizations, please take a look at our article describing how removing mixed content from your web site will improve its performance.)
Security issues
There are also important security concerns with OCSP. The fact that the majority of practical OCSP implementations were not reliable enough (either due to network lag, or configuration or application errors) motivated browsers and other client software to implement OCSP checking in soft-fail mode.
This means that if an OCSP server cannot be reached or times out while giving its response, browsers will consider the certificate as valid and proceed with the HTTPS connection anyway.
The reasoning behind this is that since an OCSP server can potentially serve millions of web sites and it is possible for an OCSP server to fail at any moment, dropping the connection on every OCSP failure would disrupt the browsing experience of millions of users. Even if the OCSP server is operating but takes a long time to reply, this adds to the perceived lag and user frustration.
Man-in-the-middle (MITM) attackers have been known to exploit this behavior by blocking all connections to OCSP responders, which effectively means that they can use a stolen certificate and key pair for a malicious site, regardless of the certificate’s revocation status.
Privacy issues
Finally, since a certificate is linked with a key and a domain name, and browsers request the revocation status before every new HTTPS connection, this means that browsers leak a significant portion of their users’ web history to OCSP responders.
Of course, publicly trusted CAs are not malicious organizations looking to compromise user privacy. (Reputable CAs are always actively trying to protect their users’ security and privacy.) However, in the event of compromise of a CA’s OCSP responder, data exchanged with that non-trusted server could lead to disclosure of sensitive and private information.
OCSP Stapling to the rescue
To mitigate these issues, browsers and CAs came up with a new method of determining a certificate’s status, called OCSP Stapling. OCSP stapling allows web servers (instead of browsers) to obtain signed OCSP responses for their certificates, that can be cached for up to 7 days.
Servers include (or staple) the cached OCSP response in their HTTPS responses alongside the SSL certificate itself. This way, browsers can verify the CAs signature on the OCSP response and be assured that the certificate has not been revoked, before the secure connection is established and without having to perform the expensive additional request to the OCSP server themselves.
OCSP stapling is a simple but very effective solution to the problems mentioned above. Servers can retrieve the cached OCSP responses in their own time, which removes the performance overhead imposed by CRLs and OCSP, as well as the accompanying privacy concerns.
However, OCSP stapling by itself does not completely solve OCSP’s soft-fail security issue. Since stapling is implemented in the server, browsers cannot know if a server actually supports Stapling or not.
As a consequence, MITM attackers with a stolen (but revoked) certificate can perform a downgrade attack by serving the certificate without OCSP stapling. A victims’ browser is not be able to corroborate whether the server actually supports stapling, and proceed to query the OCSP responder as they would normally.
MITM attackers can then simply block this OCSP query and effectively force browsers to accept the certificate as valid.
OCSP Must-Staple
This attack motivated CAs and browser vendors to introduce an extension for SSL certificates, defined in RFC 7633, commonly called OCSP Must-Staple (although the RFC itself doesn’t mention this name, which can cause some confusion.) This simply mandates OCSP stapling for the certificate. If a browser encounters a certificate with this extension that is used without OCSP Stapling, then it will be rejected. OCSP Must-Staple mitigates the aforementioned downgrade attack and it also reduces unnecessary traffic to the CA’s OCSP responders, which can also help improve overall OCSP performance.
If you are interested in enabling the OCSP Must-Staple extension in your certificates, contact one of our support agents at support@stg.ssl.com for more details.
Enable OCSP Stapling in your server
To save you the trouble of looking this up, the following sections contain instructions on how to enable OCSP Stapling in your Apache and Nginx environments:
Apache
To enable OCSP stapling in your Apache server, please add the following lines in your server’s configuration file.
# OCSP Stapling, only in httpd 2.3.3 and later SSLUseStapling on SSLStaplingResponderTimeout 5 SSLStaplingReturnResponderErrors off SSLStaplingCache shmcb:/var/run/ocsp(128000)
Nginx
To enable OCSP stapling in your Nginx server, please add the following text in your server’s configuration file.
# OCSP Stapling --- # fetch OCSP records from URL in ssl_certificate and cache them ssl_stapling on; ssl_stapling_verify on;
Conclusion
The web is an intricate network of interdependent components, all (usually) working in harmony to provide a seamless browsing experience. The ever increasing complexity of this system, however, creates an ever widening attack surface and allows new network attacks to be devised and executed.
The sheer number of the components naturally increases latency and incurs delays, which means that enterprises need to find ways to improve security without affecting user experience. Enabling OCSP stapling will give you that rare opportunity to improve security and performance for your web site at the same time.
As always, we are happy to answer your questions regarding OCSP stapling or other issues -just drop us email at support@stg.ssl.com.
