Security Sidebar: My Browser Has No Idea Your Certificate Was Just Revoked
Encryption is a fundamental reality on the Internet today. Most sites use SSL/TLS for encryption, and you can identify these sites by the https:// in the address bar of your browser. The Internet security service company Netcraft has been tracking SSL usage for over 20 years now, and their most recent data shows that there are now more than one thousand times more certificates on the web today than in 1996. DevCentral is no exception to this SSL phenomenon…go ahead, check your browser’s address bar and notice the address for this article (or anything else on DevCentral for that matter) will start with https:// instead of plain old http://. This SSL/TLS encryption provides a secure means of communication between your browser and the web server. In order to make all this encryption happen, encryption keys are shared between the web server and your browser. Encryption key exchange gets very complicated and this article is not meant to explain all the details of encryption key exchange mechanisms, but from a very high-level perspective, it’s fair to say that these keys are shared by using the web server’s SSL/TLS certificate.
When a user visits a secure website, an encryption key exchange process takes place, and the resulting encryption keys are used to encrypt all communication between that user and the web server. A certificate is a digital file that holds several pieces of information related to a particular website. One of the pieces of information it holds is the public portion of the encryption key used to encrypt all the communications to/from the web server. Another piece of information it holds is the effective dates of the certificate. After all, these things are only good for a finite period of time (typically 1-2 years).
In a perfect world, a web server would be issued a certificate and that certificate would never get compromised and it would be used for the full duration of the life of the certificate. But we don’t live in a perfect world. The reality is that certificates get compromised all the time, and when that happens, the certificate needs to be revoked. Typically when a web server certificate is revoked, a new certificate is created and used in place of the old, revoked certificate. But, how does a user know that a certificate has been revoked?
The Magic of CRL and OCSP
Here’s how it works…when a user visits a secure website, the certificate is sent from the website to the user’s browser (Chrome, Firefox, Internet Explorer, Safari, etc). Because certificate sharing creates significant computational overhead, many browsers simply store the certificate information from a previously-visited website in their cache so they don’t have to keep asking for a new certificate each time they visit that website. This is nice because it significantly speeds up the user experience for loading that particular secure website, but it also presents a problem when the certificate is no longer valid. In order to check that a given certificate is still valid, the concept of a Certificate Revocation List (CRL) was introduced. The CRL is a digital file created by a Certification Authority (the organization that creates and distributes certificates) that contains the serial number for each certificate that has been revoked by that CA. In order for a browser to check that a given certificate is still valid, the CRL must be downloaded and the serial number for the website you are visiting must be checked against the CRL to ensure the certificate is not revoked. If the certificate is not revoked, all is good and the browser displays the page. But if the certificate has been revoked, the browser should display a warning page that tells you the certificate has been revoked. Some browsers will allow you to continue to the page anyway and others won’t…it just depends on the browser. The CRL check method is computationally expensive because the browser has to download the CRL every time it needs to check a certificate (which happens very frequently), and it also has to search through the CRL for a match of the serial number of the certificate it is using (CRL files can get extremely large). In order to avoid frequent CRL downloads and searches, some browsers will cache the CRL for a given period of time and simply check the cached CRL instead of downloading a new one each time. This helps speed things up, but what if the CRL changed since the last time it was cached in your browser? This situation became a big enough problem that a new, faster solution was introduced.
The Online Certificate Status Protocol (OCSP) was developed in 1999 and it is a solution that queries an online database of serial numbers for revoked certificates. Rather than host CRL files, CAs can instead setup an OCSP server and include its URL in issued certificates. Clients that support OCSP can then query the database to see if a given certificate has been revoked, instead of downloading the entire CRL file. OCSP is a much more efficient solution than the CRL method.
Here’s a quick view of the certificate issued to f5.com. Notice it was issued by the Entrust Certification Authority, therefore Entrust is the one who manages the CRL file for all their revoked certificates and they also manage the list of serial numbers used in the OCSP queries.
The picture on the left is the detailed view of the f5.com certificate with the CRL location listed. This is the URL where the browser can go download the CRL from Entrust. Keep in mind that this CRL is just the one managed by Entrust. I took the liberty of visiting the URL where the CRL is located, and the details for the CRL are shown in the picture on the right. Notice that the CRL is simply a big list of serial numbers with revocation dates and reasons for revocation.
The following screenshot is the OCSP portion of the f5.com certificate. Notice the URL listed in the details section at the bottom of the screenshot. This is the URL that the browser will visit in order to check the current certificate serial number against the database of revoked serial numbers managed by Entrust.
So Many Certificates, So Little Time…
Now that we understand how a browser checks to see if a certificate is still valid, let’s take a little deeper look at the different types of certificates available today. There are three types of certificates you can purchase today: Domain Validation (DV), Organization Validation (OV), and Extended Validation (EV).
The DV certificate is the cheapest and most popular type of certificate. Each CA makes up its own rules as to what they require from an organization before they will issue the DV certificate. Typically it’s a very simple (and many times, automated) process like the CA sending you a file and you placing that file on the webserver at the domain in question…just something simple to let the CA know that they are issuing a certificate for a given domain to the actual owner. There are, of course, many different ways to hack this process and get a DV certificate for a domain that you don’t own. But, that’s a topic for another day.
The OV certificate is more expensive than the DV, and it takes things a bit further with respect to the CA checking that the requesting organization actually owns the domain name. There are some other organizational vetting procedures that a CA might take in order to more fully understand that the requestor is the owner. In addition to what they would do for a DV certificate, maybe they’ll make a few reference phone calls and do some simple background checks. But, then again, it’s totally up to the individual CA to develop their own procedures for vetting an organization prior to issuing an OV certificate.
The EV certificate is the most expensive, and it requires the most amount of background checking and validation from a CA before it is approved. In fact, the process for vetting an organization prior to issuing an EV certificate is governed by the CA/Browser Forum. This organization has developed a robust list of requirements that must be met before a CA can issue an EV certificate. Companies that want the EV certificate do so because they want to show the world that they are serious about the security of their online presence.
The reality is that users visit these secure sites via an Internet Browser (Chrome, Firefox, Internet Explorer, etc), so it’s interesting to see how these different browsers handle certificate revocation and also how they treat the different kinds of certificates. The top 3 browsers on the Internet today are Google Chrome (70.4%), Mozilla Firefox (17.5%), and Microsoft Internet Explorer (5.8%). Almost 94% of all Internet traffic is displayed by one of these three browsers. Let’s take a quick minute to see how these check for certificate revocation.
Google Chrome
Google Chrome is by far the most popular browser today. When it comes to certificate revocation checking, Chrome blazes its own trail and does its own thing. The CRL and OCSP methods of certificate revocation checking are the industry standards, but Google isn’t standard in this space. It has created what’s known as a CRLSet to check for certificate status. A CRLSet is Google’s own list of revoked certificates that it compiles and updates when it crawls the CRLs from the major CAs around the world. Instead of checking an OCSP responder or a CRL, Google Chrome simply checks its own CRLSet for certificate status when visiting a secure website.
Google claims that this is faster and safer for the user than the traditional CRL or OCSP methods. Some people think this approach is good because it’s faster to check a locally stored list than using the traditional methods and you also don’t have to worry about OCSP responder or CRL distribution point availability. But others are skeptical because the CRLSet is only comprised of certificates that Google deems worthy to include. What if the certificate you need to check isn’t on the CRLSet list? Also, the CRLSet file size is explicitly limited to 250KB. If something happens and lots of certificates are suddenly revoked causing the CRLSet to get bigger than 250KB (Heartbleed for example), then certificates are deleted from the CRLSet so that it stays at the 250KB max size. What if the certificate status you need gets deleted from the CRLSet during one of these bloat sessions?
Mozilla Firefox
Firefox allows you to check for revoked certificates via the OCSP method, but it doesn’t use the CRL at all. If a given certificate includes an OCSP address in the Authority Information Access (AIA) portion of the certificate, then Firefox will query the OCSP server to make sure the certificate is not revoked. If the OCSP server isn’t available or if the OCSP address is not present in the AIA field of the certificate, then Firefox won’t check revocation status and will present an error message (which the user can click through to proceed anyway). Check out the screenshot below for the settings in Firefox (version 46.0.1).
Microsoft Internet Explorer
Interestingly, Microsoft lE conducts the most comprehensive certificate revocation check of these leading browsers. The default setting is like Firefox…it checks the OCSP responder if the address is present in the AIA field of the certificate. But, if the OCSP server is not available or if the OCSP address is not present, it will then check the CRL (it checks the CRL loaded in cache if possible so that it doesn’t have to continually download a large CRL file). If neither of these is available, it will present a warning page and give the user an option of either proceeding forward with an unknown certificate status or closing out of the browser. The following screenshot shows the settings for certificate revocation checks in IE:
You can see that each browser handles certificate revocation a little different than the next. So, it’s entirely possible that a revoked certificate could fall through the cracks if Google decided not to add it to their CRLSet, Firefox couldn’t contact the OCSP server, and Internet Explorer had an outdated version of the CRL stored in cache. Be careful out there...
