June 30, 2022 0

What Is OCSP? OCSP Security Explained

in Cyber Security

(8 votes, average: 5.00 out of 5)

Loading...

How does your browser know whether a certificate is valid or has been revoked? One way of verifying a certificate’s validity is by using the online certificates status protocol (OCSP) security, which we’ll explore more in depth in this article

If you run a website, you can help maintain your guests’ privacy and security by using an SSL/TLS certificate. An SSL/TLS certificate uses public key infrastructure (PKI) to create a secure communication channel between the client browser and the website server. It also validates the identity of the server.

These certificates are issued by public certificate authorities (CAs) — trusted third-party entities — and have fixed expiration dates. The CA that issues a certificate can also revoke it prior to that date if they find anything wrong with the issuing keys associated with the certificate or the intermediate and root CAs it chains back to because it’ll no longer be trustworthy. (PKI digital certificates like SSL/TLS certificates are all about trust.)

So, how can you be sure that the websites you visit have functioning TLS certificates? And how will you know if any given website’s TLS certificate has been revoked? OCSP security is one answer. In this article, we’ll explore the online certificate status protocol in detail and why it’s such an important relating to website security.

What Is OCSP Security? A Look at the Online Certificate Status Protocol

The online certificate status protocol (OCSP) is one digital certificate revocation status verification method. It helps your browser check whether the website security certificates on the sites you visit are still valid and haven’t been revoked.

OCSP is an internet protocol that requests the status of a specific website’s X.509 digital certificate from the issuing CA’s OCSP response server. This resource maintains a list of information relating to certificates that have been revoked or replaced that’s frequently updated.  

Why is this necessary? Because if a website relies on an outdated or revoked certificate, this can cause a litany of security issues and means that the certificate is no longer trustworthy. There are different reasons why a TLS certificate could be invalid, such as:

• The private key is compromised
• The CA is compromised or has been removed from the network
• The certificate owner is no longer with the organization
• The organization has ceased normal operations, and the certificate has been replaced

For a more technical definition and description of OCSP, you’ll find it covered in the Internet Engineering Task Force’s (IETF) request for comments (RFC) 6960.

What Are the X.509 Digital Certificates That OCSP Checks?

X.509 is a technical term that defines the format of public-key certificates. A public-key certificate is a critical part of public key infrastructure (PKI), wherein public and private keys are used for encryption and decryption. These certificates provide verified identifying information about the certificate subject (i.e., the person, organization or website that the certificate was issued to).

In general, X.509 certificates are commonly used for the following applications:

• Securing the website’s data in transit: SSL/TLS certificates are a type of X.509 certificates used to create a secure channel between browser and server for transferring the data. If you see a padlock or HTTPS in the address bar, an SSL/TLS certificate is in place.
• Digitally signing and encrypting emails: Secure/multipurpose internet mail extension certificates (S/MIME certificates) are used to secure email integrity so you can be sure that the email has not been tampered with. S/MIME also uses the public-key infrastructure for encryption.
• Digitally signing your code and documents to ensure file integrity: Code signing certificates are used to prove the integrity of software to the user so they can trust that no unauthorized third party has made any changes to the software. The developer or publisher can ensure that their code is not tempered for malicious purposes.
• Securing payments made through digital payment cards: Europay, MasterCard, and Visa (EMV) refers to the chip inserted in the debit, credit, and other cards to increase security when making payments. These chips use X.509 certificates to improve security using PKI.

When talking about OCSP, we’re specifically referring to a way for a user’s browser to check the status of SSL/TLS certificates for websites and web apps. Note that sometimes, people incorrectly refer to “OCSP certificates.” Actually, there is no such thing as an OCSP certificate. What they usually mean is a valid SSL/TLS certificate.

Why Was OCSP Developed?

Before OCSP, browsers relied solely on certificate revocation lists (CRLs). A CRL is a list of digital certificates that have been revoked by a certificate authority. They are stored in a shared CRL distribution point and are updated periodically. The CA/B Forum  has the following time periods/frequency requirements for CRLs:

• Subscriber certificates: The CA shall update and reissue CRLs at least once every seven days. The CA should not take more than ten for the next update.
• Subordinate CA certificates: A CA can publish a subordinate CA certificate revocation list once every twelve months. However, they should publish a revised list within 24 hours of the revocation of the subordinate CA certificate.

The CA that issues the digital certificates also verifies the ownership of the certificate’s public key.

The CA/Browser Forum (CA/B Forum), a consortium responsible for setting and implementing the guidelines for public-key certificates, no longer requires the use of CRLs specifically. CAs still choose to use them or opt for providing OCSP responses instead. Either way, all publicly trusted certificate authorities must maintain a repository of some kind (CRL, OCSP responses, etc.) that includes certificate status information.

CRLs have several limitations which have led to them gradually being phased out in favor of OCSP:

• No real-time updating. CRLs don’t provide real-time information on the status of the certificates. Because there can be a gap between when the certificate is revoked and when the list is updated, the client could, unknowingly, accept a revoked certificate.
• Browser parsing of the certificate revocation list. The browser must parse the CRL to determine whether a particular certificate is valid. The amount of data to be parsed places a large burden on network and client resources.
• CA server downtime. If the CA’s server is unavailable even temporarily, it means the CRL is also unavailable. (Note: OCSP responders would also be unavailable in this scenario.) This means the browser can’t complete the verification and is at risk of several types of attacks. OCSP stapling can be the solution to server downtime issues. In OCSP stapling, the server downloads its own certificate verification time-stamped and signed by the CA at regular intervals. We will discuss OCSP stapling more in-depth later in the article.
• Browser and OS compatibility. Not all browsers or operating systems are compatible with CRLs.

OCSP was designed to overcome several of these limitations, and the CA/B Forum has shifted towards using and recommending OCSP rather than CRLs.

How Does OCSP Work? A Step-By-Step Look at the Process

Before it loads a website, a browser must check if the website certificate is valid. While using OCSP, the client sends a request to the OCSP responder (or OCSP server) to check the status of the specific certificate of the website that it is trying to access. On the other hand, with CRLs, the client browser downloads and parses the entire CRL from the CAs centralized CRL distribution point.

The OCSP check happens in real time and confirms whether the server has a current or revoked TLS certificate. There is also an “unknown” state, where not enough information is available or the client receives no response from the OCSP server.

An OCSP status check goes like this:

1. A client and a server want to communicate.
2. The server sends its public key certificate to the client.
3. The client verifies the validity of the certificate by sending an OCSP request with the certificate serial number.
4. The OCSP responder (or OCSP server) takes the serial number of the certificate from the request and verifies the revocation status from the CA database.
5. The OCSP responder returns a successful signed response to the client if the certificate is valid.
6. The client uses the CA’s public key to verify the digitally signed response.
7. The client completes the transaction with the server.

A visual representation of the OCSP verification process

Note that the CA might be the OCSP responder. In that case, the CA database would have information about the revocation of the certificate. Then, the CA might use their CRL for status verification.

Server Response Values and Soft- and Hard-Fail Policies

The OCSP request returns one of the following three responses:

• Good: This response means that the X.509 certificate is valid and hasn’t been revoked.
• Revoked: This response indicates that the CA has revoked the certificate you are trying to access before expiration. This message will result in the connection being terminated and is known as a hard fail.
• Unknown: The above two responses were pretty obvious, however, the ‘Unknown’ response is received when the browser is unable to check the revocation status of a PKI certificate. In this case, the browser might accept the certificate and allow the connection (whether it does or not depends on the browser and its configuration). This response, which is known as a soft fail, can result in a technical failure (non-malicious fail) or a security breach (malicious fail).

Although the probability of a malicious attack is low, it is possible. If the browser connects in such cases, the user could fall victim to an attack. This means that OCSP is not completely secure. But despite this limitation, it has many advantages over the CRL method.

Limitations of OCSP Security

As well as the possibility of security breaches in the case of a soft fail, OCSP has some other limitations, such as:

Increased Costs for the CA

Costs for the CA can increase significantly as they have to provide information about certificate status in real time rather than periodically publishing a list of revoked certificates. The more website traffic, the higher the cost for the CA, as each user requests the information separately.

Of course, you don’t care about that, right? Maybe you do and don’t know it. After all, the CA may pass those increased OCSP response costs along to the customers as additional charges. For example, Amazon Web Services charges you extra when turn on your OCSP feature — a fixed monthly fees plus variable fees based on the number of queries.

Client’s Dependence on OCSP Responder Increases

A client depends on the OCSP responder to facilitate their connection with the server. If they can’t connect with the OCSP responder, they won’t be able to check the status and will have to take a leap of faith if they decide to visit the website.

Reduced Speed

OCSP slows down browsing speed as every time the user wants to connect to the website, they must verify the current status of the TLS certificate.

What Is OCSP Stapling?

Depending on whom you ask, OCSP stapling is a step up from the traditional OCSP protocol. With OCSP, the client makes the request for verification, whereas with OCSP stapling, the request is made by the server. So, the burden of responsibility shifts from the client to the server, and so does the cost. The TLS client must include the certificate status request extension ‘stapled’ in its TLS ClientHello handshake message if it wants to use OCSP stapling.

OCSP stapling is much faster than simple OCSP and gives a better overall experience to the client. The client doesn’t have to ask for the information when they visit a website — the server does that for them. Then, every time a client opens the website, the server is ready with updated data of the security certificate.

OCSP stapling is trustworthy because the CA that initially issued the server certificate sends a signed, time-stamped response to the request. Therefore, the client can fully trust the response. We’ll explore OCSP stapling further in an upcoming post.

What Is OCSP Must-Staple?

OCSP must-staple is a certificate extension for verifying the revocation status of X.509 certificates. Basically, the client receives a heads-up that it should receive a stapled response to the TLS certificate query that doesn’t allow a soft-fail. If the browser doesn’t receive a valid OCSP response, it should send a hard-fail and not go through with the connection.

The primary drawback of OCSP stapling is that it connects despite a soft fail. OCSP must-staple eliminates this issue because the web server securely informs the browser to expect an OCSP response. If the browser doesn’t receive any response from the server, it treats it as a hard fail and won’t connect.

A website owner or administrator decides whether their website will support OCSP must-staple. If they do support it, their website will have an object identifier (OID) extension in the TLS certificate that lets the client know that it is receiving OCSP staple when the server sends over its SSL/TLS certificate.

OCSP must-staple is a big leap for website security. Unfortunately, it’s not supported by all web servers and browsers, so it’s not yet fully operational. We’re keeping our fingers crossed for full acceptance of OCSP must-staple soon.

Differences Between OCSP, OCSP Stapling, and CRLs at a Glance

Let’s summarize the difference between these forms of OCSP security certificate revocation verification:

CRL	OCSP	OCSP Stapling
Downloads the entire list for every query	Only data relating to a particular serial number (i.e., a specific digital certificate) is returned	OCSO stapling also returns the data relating to the particular certificate’s serial number.
Uses more client and network resources	Uses fewer client resources	Uses the least client resources as it is the server’s responsibility to provide verification
An older solution for certificate life cycle management	Currently an IETF industry standard for certificate life cycle management	OCSP stapling is the way forward
Doesn’t provide that may be outdated	Provides real-time information	Provides almost real-time information
Users send the request to a shared CRL distribution point (CDP), so privacy might be compromised	Websites send the request to the CA or its OCSP responder, so there have been some concerns about data privacy	The server sends the request to the CA and presents it to the client, ensuring total privacy

The difference between the response to a request from CRL and OCSP are shown below. As you can see, with a CRL, the CA provides a list of all revoked certificates. With OCSP, the responder only sends the status for specific certificates. 

Final Thoughts on OCSP Security

OCSP security is a widely accepted method to view the current status of X.509 certificates and was developed to be an improved method for verification over the previous method, certificate revocation lists. Although OCSP is a big improvement on traditional CRLs, it still has its limitations.

Security experts are working towards implementing the successors to OCSP — OCSP stapling and OCSP must-staple. It will be interesting to see where these new innovations in the field of cybersecurity will lead.

• #OCSP