By
David Warburton, Senior Threat Research Evangelist, F5 Networks
July 31, 2018
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?
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 notappear on this list, then the user is okay to proceed.
Figure 1: CRLDP Checking
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.
To remove the manual step of importing a CRL file, a CRL Distribution Point can be configured so that the web server (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 PKI shows 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 ecommerce 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.
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
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:
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 2018in Boston, MA August 13-16. For more information on how F5 can help deliver secure authentication please visit f5.com
Related posts
In the meantime, please explore more of our solutions
