In my last post, I examined the reasons why certificate revocation is important to enterprise security. Now I’ll walk you through the steps you need to follow to check for revoked certificates.
Certificates are believed to be ‘good’ unless we’re told otherwise, so certificate authorities simply need to maintain lists of ‘bad’ certificates that have been revoked. These lists are then made available so that anyone can query the status of a certificate. For the most part, if the certificate we are checking does not appear on a list, we can assume it’s okay.
Many methods exist for publishing and querying these lists but few of them are widely used. This is largely because the methods are slow, prone to failure or are just plain complicated to understand and implement. So, what are the methods and what problems do they have?
PKI: Are You Doing It Wrong?
How to Check Certificate Revocation Lists (CRL) for Revoked Certificates
The most basic form of revocation check available is the CRL. A basic text file created by the Certificate Authority which must be manually uploaded (regularly) to the device which is to perform the revocation checks. The authenticating device (such as a web server or Application Delivery Controller (ADC)) checks this list for every session it must authenticate. If the certificate presented is valid and does not appear on this list, then the user is okay to proceed.
Figure 1: CRLDP Checking
The CRLDP checking process is:
- Client connects to site and performs TLS/SSL handshake
- ADC sends back server certificate
- Client reds location of CRL and fetches it from CA server
- CA server sends CRL back to client
- Client checks entire CRL for matching cert hash
CRLs are technically very simple to use but operationally difficult to implement. They are often not updated frequently enough and are tedious to manually import to authenticating devices (such as the ADC). In addition, they can grow very large and there may be multiple CRL sources that you need to consider.
CRL Distribution Points (CRLDPs)
To remove the manual step of importing a CRL file, a CRL Distribution Point can be configured so that the webserver (ADC) can automatically read it in from an online source, typically over HTTP(S) or LDAP. But, while this solves one problem, the others remain. One of the larger problems, speaking literally, is that of the size of the CRL itself.
A 2015 paper An End-to-End Measurement of Certificate Revocation in the Web’s PKIshows that while new CRL files may be only dozens of bytes in size the average CRL file for many Certificate Authorities can be 0.5MB with the largest seen over 7MB. In our e-commerce environment, each user would see their web browser manually download this list to ensure the site they are connecting to has not had its certificate revoked.
Online Certificate Status Protocol (OCSP)
Clearly, the exponential growth in the size of CRL files meant that another solution was needed. OCSP was created and aimed to solve that problem. The process is similar to that of CRL checking with the difference being that the client now only needs to fetch the status of the particular certificate in which it is interested, rather than the entire list.
Figure 2: OCSP Checking
The OCSP checking process is:
- Client connects to site and performs TLS/SSL handshake
- ADC sends back server certificate
- Client reads location of OCSP and sends query to CA
- CA server sends OCSP status back to client
This is a much more efficient way for clients to check on the status of a certificate. However, serious problems with this system still cause problems today:
- The number of queries hitting OCSP responders (the CA server) can be high since every client must check the status of every certificate
- It is a privacy leak – the OCSP responder now has a potential log of every client IP and the name of the website they wish to visit
- The whole process is still slow since the client has to make another series of round trips to connect to and query the status of a certificate. If you are on a high latency connection such as a poor mobile network or satellite connection, this could be hundreds of milliseconds in each direction
A significant vulnerability also exists with the OCSP protocol. Steps 3-4, in the example shown in Figure 4, may be intercepted by an active attacker. This man-in-the-middle (MITM) attack is impossible for the client or OCSP server to detect. Although web browsers will send off the request to the OCSP service it will happily give up if the response takes too long. Why is this? Well, if web browser A took 3 seconds to load a web page and web browser B took only 1 second, which browser would you regularly use?
In my next post, I will outline a strategy that you can follow to improve the effectiveness of OCSP in your organization.
Come see how Venafi and F5 are working together to simplify machine identity protection at F5 Agility 2018 in Boston, MA August 13-16. For more information on how F5 can help deliver secure authentication please visit f5.com
(This post has been updated. It was originally published on September 3, 2019.)
TLS Machine Identity Management for Dummies
Related posts