The Value of Certificate Revocation Lists (CRLs) in a PKI
In Internet explorer, inside Tools --> Internet Options --> Advanced there are two controls for revocation checking. Check for server certificate revocation controls whether revocation checks occur for HTTPS connections. Check for publisher’s certificate revocation controls whether revocation checks occur when validating the Authenticode digital signatures on downloaded programs and ActiveX controls. Microsoft’s recommendation as noted in Security Compliance Manager for server certificate revocation checking in IE8 and IE9 is to enable this setting.
In a recent announcement by Lucian Constantin, it was noted that Google Chrome will no longer check for revoked SSL certificates online. The article begins discussing a background of how:
“Google plans to remove online certificate revocation checks from future versions of Chrome because it considers the process inefficient and slow.”
There is little doubt that in some cases revocation checking can actually be slow if it is not designed appropriately or if there are mitigating factors like large Certificate Revocation Lists (CRLs) transferred over networks lacking the bandwidth capacity for timely delivery or even too many clients checking in far too often to download full CRLs. This can be the case on Internet facing sites and could affect HTTPS site verification performance for some sites. However, lets take a look at how CRLs work, and recommended practices for ensuring optimal performance for a PKI.
Certificate Revocation List (CRL) - A CRL is really just a list of revoked certificate serial numbers that has been digitally signed by a Certificate Authority and time-stamped and placed in a public in a repository such as a web site. Applications that use certificates have the option of checking the CDP repositories for CRLs. Many applications ignore CRLs altogether while other applications check CRLs and choose what to do if the certificate has been revoked as is the case with many web browsers.
There are different kinds of CRLs that are generally published on repositories known as CRL distribution points or CDPs:
- Full CRL or Base CRL - The most common and widely supported are the full CRLs also known as base CRLs which contain serial numbers of all revoked certificates for a particular Certificate Authority (CA).
- Delta CRL – Delta CRLs contain the list of serial numbers of only certificates that have been revoked since the last Base CRL was published.
One of the challenges with designing a PKI is to determine the best publication interval, and there are several factors to consider.
CRL Publishing considerations:
- Publishing a base CRL more frequently, revoked certificates could be more quickly known, but the CRLs are downloaded more often, and consequently as the CRLs grow can generate more traffic for the full CRL downloading by all clients.
- Publishing CRLs less often can increase the latency before a client becomes aware of a newly revoked certificate, but may reduce overall network traffic because CRLs are downloaded less often.
Care has to be taken to make sure the PKI is designed with these considerations in mind.
Delta CRLs which are much smaller than base CRLs generally are defined in RFC 2380 and allow base CRLs to be downloaded at intervals further apart with more frequent downloads of the delta CRL. This allows for more frequent updates to the known revoked certificates without the necessity to download the full CRL very often. Not all devices or applications recognize delta CRLs.
OCSP - for real-time validation, the Online Certificate Services Protocol (OCSP) is an HTTP protocol that acts as an intermediary to responder to clients that support the protocol. The OCSP response is a digitally signed response for the certificate status, but the response size does not change regardless of the number of revoked certificates. On the back end, the OCSP responder generally relies on CRLs. The advantage with OCSP over CRLs, is that in the event of a revocation that requires near immediate response a new CRL can be published and the OCSP responder can be configured to get the new CRL at a pre-determined interval (i.e. a few minutes) rather than waiting on the next update cached in the CRL.
If CDPs are highly available, distributed appropriately and publishing frequency published with careful consideration to the factors involved such as latency, network traffic, and CRL then they can be efficient at providing accurate revocation information. Further optimization can be achieve if clients support Delta CRLs, and the OCSP protocol.
The aforementioned announcement goes on to state:
If browsers were to insist on talking to the CA before accepting a certificate, all these cases would stop working. There's also the concern that the CA may experience downtime and it's bad engineering practice to build in single points of failure.
CRL Distribution Points - Recommended practices for CAs are that CDPs be placed on highly available servers that are resilient to downtime and outages. In fact an outage of a certificate authority should not affect the availability of CRLs unless the CA is down for an extended period of time extending beyond the next CRL publishing interval. Even in those cases, the CRL can be re-signed with the CA’s private key even if the CA is unavailable.
Furthermore, the discussion focuses on an attacker scenario where:
If the attacker is close to the server then online revocation checks can be effective, but an attacker close to the server can get certificates issued from many CAs and deploy different certificates as needed.
Certificate Issuance - In general, recommended practice for a PKI is to limit certificate issuance to only authorized recipient users and devices approved by the certificate manager. If the CAs are well-protected with good physical and logical security and the private keys secured and possibly protected by hardware security modules (HSM)s then the attack surface on the CAs themselves is greatly reduced as is the likelihood of CAs issuing certificates to unauthorized entities.
Most of the successful attacks on HTTPS sites require control of both the certificates and the DNS.
Examples:
The assertion here also suggested that “While the benefits of online revocation checking are hard to find, the costs are clear: online revocation checks…compromise privacy.” What is the “privacy concern because the CA learns the IP address of users and which sites they're visiting?” A web browser or any application can check revocation using CRLs or OCSP from a CDP, but typically not a CA if following recommended practices for protecting CAs.
SSL Authentication - If a client visits a secure sites (https), then the browser may check revocation status of the SSL certificate on that site (server) and optionally server will do the same for the certificates on the client, but these will usually checked against different CDP altogether unless client and server were published from the same CA. In this type of scenario, two different IP addresses for client and server check revocation against two different CDP locations for the others’ certs. The general case for this does not lend itself to a loss of privacy using CRLs or OCSP for SSL communications.
While the future of PKI and certificate trust model may change in the future; for the foreseeable future, CRLs still have an important role and provide tremendous value for PKIs