Why OCSP Stapling is the Best Method for Checking Certificate Validity
1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading...

Why OCSP Stapling is the Best Method for Checking Certificate Validity

SSL Certificates are a vital piece of secure internet communication, but only if they can be relied on to identify websites accurately.

Behind the scenes of your browser some Disney-esque magic is happening when you connect to a site using HTTPS (the secure web protocol enabled by SSL/TLS). In just a second or two you receive an SSL certificate from the web server, cryptographically prove (or disprove) the certificate’s legitimacy, exchange technical capabilities, and start encrypting and exchanging data.

One of the key parts of this process is checking the certificate’s digital signature. The signature tells your browser if the certificate is legitimate, and if it is, it gives the browser assurance that you are talking to the proper site, and not an imposter spoofing the site or tampering with the connection. Each and every time you connect to a site using SSL, your browser checks its certificate’s signature for legitimacy.

However, there are some situations where a signature can’t be trusted.

In this post we are going to explain revocation – a mechanism which allows browsers and devices to know when a certificate is no longer safe to us. Revocation is a normal part of any PKI system, which SSL/TLS is, and helps correct for the realities of human error, server compromise, and other consequences of real world use.

The rise in popularity of free SSL certificates – as offered by providers such as Let’s Encrypt and Symantec’s Encryption Everywhere program – has made revocation even more important. Free SSL certificates are an amazing new trend that will help spread secure transmissions to the long-tail of the web, but they do not come without drawbacks. Hackers and other malicious users like to take advantage of free certificates because it means less out of pocket expense for their illegitimate online activity. The ability to acquire a large number of free certificates also makes it easier to exploit vulnerabilities which may exist in the CA’s systems.

Luckily, revocation severely limits the effectiveness of using SSL certificates for harm. In this article, we will be talking about one revocation method in particular: OCSP Stapling. It is by far the best option for efficient and quick revocation. Before we dive into what OCSP Stapling is though, we have an introduction to revocation for those who are unfamiliar.

Background: An SSL Certificate’s Function, or: Why Revocation is Needed

Before we talk about revocation, let’s look at why having accurate and up-to-date validity is so important for SSL certificates. When a site uses SSL it is providing the connection with two security features: encryption and authentication. The encryption is provided by the SSL/TLS protocol. The authentication is provided by the SSL certificate. Both features are necessary to provide a secure connection. But in this article, we are mainly concerned with SSL certificates and authentication

Every SSL certificate has a “subject” which identifies what entity is has been authenticated for. At a minimum, this subject is the domain name the certificate is intended for use with. Some SSL certificates’ subjects also include the legal company that owns/operates the domain name.

OCSP Stapling
The Subject information for TheSSLStore.com’s EV SSL Certificate. All SSL Certificates include the domain name that the certificate is intended for, indicated in the certificate as the “CN” (Common Name). If a connection is attempted with a certificate intended for a different domain, the browser will prevent a secure connection. EV Certificates also include the legally incorporated business/organization which owns the domain.

The SSL Certificate’s subject must match the domain name you are visiting for a browser to make a secure connection. This is to ensure that someone does not use a legitimate certificate in a malicious attack – for example, the SSL certificate for “www.google.com” can only be successfully used on “www.google.com.” Using it with any other website, like say a phishing site intended to replicate Google.com, causes a major error.

Remember that this is all reliable because a trusted Certificate Authority (CA) has validated that the information is correct, then cryptographically signed the certificate to prove that fact.

Every SSL Certificate also has its own “key pair,” which includes the encryption and decryption keys used to securely transmit the data from your browser to the server. These keys are different for every SSL certificate. One half of the key pair – the public key, which handles encryption – is part of their SSL Certificate file.  The other half – the private key, which handles decryption – is securely and privately kept by the certificate owner on their server.

This key pair is one of the primary reasons that certificate validity and authentication is so important. When a browser allows a secure connection with a specific certificate, it is essentially saying “this public key is owned by the domain you are visiting, it is currently valid, and it is safe to encrypt your data with this public key and send it to this server for decryption with the corresponding private key.”

You don’t want to be making a secure connection and sending your data to a website that has not been authenticated, and you don’t want to do so with a certificate whose encryption keys may have been compromised.

So, to summarize: Every certificate has a subject. That subject is cryptographically verifiable. Your browser will make sure the site you are visiting and the certificate’s subject match. When they match, and the signature is valid, the browser knows the public key within is really owned by that website. The browser can then establish a secure connection, knowing that it’s able to reliably provide both encryption and authentication. This is only a summary – there are all sorts of other checks that the browser performs to ensure the security of the connection, which we skipped for the sake of simplicity.

If the browser didn’t know WHO owned that key pair (or couldn’t rely on that information being accurate), then it couldn’t make a determination if it was okay to use the SSL Certificate.

What Is Revocation

Websites acquire SSL certificates from companies known as Certificate Authorities (CAs) – you may know the industry leaders, such as Symantec, Comodo, and DigiCert. When a CA receives an application for an SSL certificate, they follow industry-standard requirements to insure the application is legitimate and that they are giving the certificate to the website’s real owner/operator.

Assuming everything checks out, the CA will issue the certificate. In order to tell to all the browsers and devices (like your computer) that the certificate is legitimate, the CA will include a digital signature, which is cryptographically secure. Before making a secure connection with the site, your browser will make sure the signature checks out.

These digital signatures can remain valid for up to 3 years. But during that time, something might happen where the CA wants to make sure that signature is no longer trusted. This process is called revocation.

Revocation may be needed for any number of reasons, including key compromise (when the encryption keys being used by the certificate are stolen or leaked on the internet) or mis-issuance (when the certificate was issued to the wrong person, or with some sort of mistake like a typo or inaccuracy).

There has been more than one attempt to design a system that can handle revocation for the whole internet. The three revocation mechanisms are: Certification Revocation Lists (CRL), Online Certificate Status Protocol (OCSP), and OCSP Stapling (a better implementation of “vanilla” OCSP).

From a technical standpoint, each mechanism works differently. But their end goal is the same:

To tell you if a certificate is still valid and can be trusted, or if it has been revoked and should not be trusted.

How Revocation Works

As we mentioned earlier, a certificate’s digital signature is provided at issuance, so after a certificate has been created, it will be “trusted” and accepted as valid until it expires (or if an attempt is made to use it with a different site).

Revocation mechanisms allow for CAs to report certificates that should no longer be trusted despite still being in their validity period.

These mechanisms work by allowing CAs to report certificates that have been revoked, and a way for browsers to receive that information while attempting a connection with a website. If a certificate has been reported as revoked, the browser will abort the connection.

Revocation can be requested by the certificate’s owner, at the request of a third party (for example, a person or company who knows the certificate is being used for malicious purposes), or done directly by the CA (for example, in the case of a well-publicized key compromise. The CA can revoke any of its certificates without permission from the certificate owner).

The first attempt at a revocation method is known as CRL (Certificate Revocation List), originally introduced in 2008. As the use of SSL (and the internet itself) grew, it quickly became clear CRLs were not going to work.

One of the main problems with CRLs was scale. It became increasingly inefficient as the number of revoked certificates increases. Since then, more attempts have been made at solving revocation, the newest, and most effective mechanism, is known as OCSP Stapling.

OCSP Stapling allows for the smallest window between when revocation occurs and when browsers are notified, and the best performance when retrieving that information.

We will only be briefly describing the technical process of revocation here, so if that interests you, I have written about it in a separate article, which also goes into much more detail on the CRL mechanism and the history of revocation.

How OCSP Stapling Works

Here we are, the main attraction:  OCSP Stapling.

So, how does it work?

When an SSL connection is attempted, the browser and client initiate the “SSL Handshake” – this is the formal name for the process we have been informally referring to as “checking” the certificate. This is a multi-step process where the browser receives the website’s certificate, looks for a valid signature, decides on the encryption parameters, etc.

One part of the SSL Handshake is certificate validity checking – this is where the browser will use the available revocation method(s) to see what the certificate’s status is. The OCSP Stapling process happens here.

OCSP Stapling has a few components, and is easiest to understand when broken down step-by-step:

  1. Before any connection even happens, the SSL Certificate is issued by the CA. The certificate includes an indicator that it supports OCSP. This is how a browser knows it should use OCSP for revocation checking. This is now an industry standard – all CAs must provide an OCSP service and issue certificates that support OCSP.
  2. The CA who issued the certificate continually publishes information about the certificate’s validity to an OCSP Responder, which is the formal name for server(s) they operate that are tasked with handling OCSP.The CA publishes the current validity status about every certificate it has issued, not just the ones it has revoked. Industry requirements stipulate that OCSP information is updated at least every four days.[1]
  3. The end-user, using their browser (the client in the SSL connection) wants to visit FavoriteWebsite.com (the server in the SSL connection). They navigate to that site.
  4. The SSL Handshake between the client and server begins…(The handshake includes a series of other steps which are unrelated to OCSP)
  5. FavoriteWebsite.com’s server fetches an OCSP response from the OCSP Responder. The OCSP response contains the certificate validity information. An OCSP Response can report one of three certificate statuses: good, revoked, or unknown.[2] For performance reasons, the server is not expected to get a fresh response for every single connection. Instead, the server fetches a response and then caches it, which it can re-use for all connections for up to 10 days. This allows the server to attach the response with their certificate with no delay.
  6. FavoriteWebsite.com provides their SSL certificate to the client, and “staples” (attaches) the OCSP response. The client receives the certificate and the OCSP response together.This step is what distinguishes OCSP Stapling from vanilla OCSP. In vanilla OCSP, it is the client (the browser), not the server, which is responsible for getting the OCSP response. The client queries the OCSP Response directly from the OCSP Responder, and pauses the SSL Handshake as it waits to receive it. This is a cause of numerous security and performance problems.
  7. The SSL Handshake then completes.

Assuming the OCSP response was “good”, and that there are no other errors, the SSL connection has been established and secure browsing begins!

Advantages of OCSP Stapling

Certificate revocation for the entire internet is a tough problem to solve, and OCSP has benefitted from the failures of earlier solutions. It offers:

  • The Fastest Certificate Revocation Information:OCSP Responders are updated faster than any other revocation methods, giving browsers the fastest access to current information about certificate validity. CAs are required to update OCSP information at least every four days.OCSP information can be updated immediately, and in severe situations a CA may choose to do so. Revocation due to key compromise or malicious certificate use is much more severe, than, say, a user requesting revocation because they are no longer using the certificate.The longer it takes for revocation to be reported, the longer the window is open that certificates can be used. CRL allows for a longer window, therefore posing more security risk.
  • Best performance of any revocation mechanism:Previous revocation mechanisms were not widely used because of their performance problems. Real-world performance of CRLs was laughable. It was not uncommon for a specific CRL to grow to a megabyte or more – potentially being bigger than the actual page being visited. Vanilla OCSP burdened the client with an entire separate series of TCP connections, which posed so many performance and logistical problems that most of the major browsers have entirely given up on it.OCSP Stapling was designed to correct the performance issues of previous mechanisms. An OCSP response is only a few kilobytes – essentially the size of an SSL certificate – and is delivered in-line with OCSP Stapling. It is the most efficient method for delivering certificate validity information.
  • No Privacy Problems:The way that vanilla OCSP was implemented posed a major privacy issue. Clients retrieved OCSP responses directly from the OCSP responder operated by the CAs. This meant that CAs, and anyone monitoring those responders, knew who was visiting what sites. If vanilla OCSP had become widely deployed, it would have been a gift for large-scale internet surveillance programs. “It’s much easier to monitor the traffic flowing to a dozen or so major OCSP responders than to eavesdrop on the actual traffic of the entire world.”[3]OCSP Stapling fixes this problem. Because the server fetches the response, there is no additional information leaked about the client.

Conclusion

Certificate revocation is a necessary piece of the Certificate Authority model that the internet uses for SSL/TLS.  Historically, making revocation technically feasible was a problem.

OCSP Stapling has largely solved this by making revocation reporting fast, efficient, and cheap. Support for OCSP is an industry requirement, so all SSL certificates can benefit from this technology.

From a technical perspective, no revocation method will ever be perfect. Even OCSP Stapling is continuing to improve. New additions to the standard, which are still being adopted, including “must-staple” and “multi-stapling,” will make OCSP more secure and ensure it keeps up with the industry’s rising expectations.

[1] CA/B Forum Baseline Requirements, V 1.3.7, Section 4.9.10

[2] There are other responses for various errors that may occur, including the OCSP Responder malfunctioning.

[3] Ivan Ristic, Bulletproof SSL and TLS. Pg.145