Defective By Design? - Certificate Revocation Behavior In Modern Browsers

With the recent fraudulent certificate incident involving one of Comodo's RAs there is a renewed interest in the quality and reliability of the revocation infrastructure surrounding X.509 certificates ("SSL"). Adam Langley, a researcher at Google, coincidentally wrote a blog post entitled Revocation Doesn't Work deriding the system several days before the compromise became public knowledge. However, the situation is more complex than many have intimated.

First, some background and a description of the idealized revocation environment. Revocation in X.509 is at its core a list of certificate serial numbers that should no longer be trusted. A client asks the CA whether or not a certificate can be trusted in one of two ways.

Ways To Request Revocation Information

The first is called a certificate revocation list (CRL). CRLs are generated on a per root basis and list every serial number that has been revoked and the date they were revoked¹ along with a notBefore and notAfter date for the CRL itself. Each CRL is signed by the root² itself to allow clients to validate that the list is genuine and currently within its validity period. This allows CRLs to be distributed over HTTP by the CA³ and cached so they do not need to be re-fetched by the client constantly.

The second method by which a client can obtain revocation information regarding a certificate is via Online Certificate Status Protocol. OCSP responders accept requests that contain a serial⁴ and reply with a signed statement about that single certificate. This avoids the potentially large overhead of downloading a CRL and ostensibly means you can get "fresher" revocation information about a certificate⁵.

Idealized model

1. A website operator decides they want to secure their shopping cart using SSL. This person heads to a certification authority (CA) and buys an SSL certificate from them for "www.mygreatexamplecart.com".
2. The CA performs validation⁶, issues the certificate, and the customer⁷ installs it on their server.
3. Unfortunately, a few weeks later their server is hacked and the private key for that certificate is stolen.
4. The subscriber now contacts the CA and requests revocation (and a new certificate to replace the revoked one).
5. The CA adds the compromised certificate's serial number to their revocation list and OCSP responder.
6. The relying party⁸ can rest easy knowing that their browser will now tell them if the certificate is ever seen again.

Reality

In practice there are many issues with the scenario described above. Among the biggest is that revocation information is a blocking operation. This means that you don't want to actually load anything from a site until you know the cert is trustworthy. So therefore to load any SSL secured website you need to have known valid revocation information for the certificate before you make your requests. This means that your SSL secured site's load time is dependent on the speed with which the browser can fetch revocation data from the CA's repository⁹. But wait, there's more! What if the CA's revocation infrastructure is unreachable? There are many reasons why it might be down: normal downtime, you're experiencing an attack and the attacker has chosen to break revocation responses, or maybe it's just over capacity. In the real world reachability and latency affect CRL/OCSP so much that browsers have been forced to ignore revocation information when unavailable. But things get even murkier if you start looking at the "types" of server certificates¹⁰.

Domain Validation (DV)

Domain validated certificates are by far the most popular (and cheapest) certificate available today. Their vetting methods vary by CA¹¹, but they're almost entirely automated and rely on domain ownership being proven by means of a beacon (a file placed on the webserver at the domain) or receipt of an email to an acceptable list of email addresses (typically the Mozilla approved list of 5). No major browser checks CRL or OCSP on these certificate types by default. So even in our idealized situation above the relying party would not know the certificate has been revoked.

Organization Validation (OV)

Organization validated certificates are similar to DV, but they include some level of organization vetting (and subsequent inclusion of org name within the certificate fields). These certs obtain the same visual lock indicators that DV certs have in browsers so there is no way to distinguish between the two without examining the certificate itself. Again, no major browser checks CRL or OCSP on these certificate types by default. So even in our idealized situation above the relying party would not know the certificate has been revoked.

Extended Validation (EV)

The newest of the certificate types also carries by far the most comprehensive vetting procedure. Unlike the other two types, EV standards are dictated by the CABrowser Forum. EV was developed in response to the perceived degradation of validation quality (and overall certificate trust) that occurred when DV was introduced. Browsers present a different UI for EV certificates to try to demonstrate to the relying party that the site in question has undergone a higher level of validation. This UI typically shows the organization's name. Revocation is checked (CRL or OCSP, depending on browser and OS), but if the revocation server does not provide a well-formed reponse there are many possible responses depending on browser.

Browser Revocation Information Tables

OVChecks OCSP if AIA is present, no CRL checkEVChecks OCSP (no CRL) and if no response/invalid response removes EV presentation, making it look like OV

Firefox 4 Screenshots

Firefox EV presentation:
Firefox EV when revocation data is blocked/returned as invalid:

OVDoes not check by default on Mac/Windows (Linux unknown)EVChecks and if no response/invalid response puts up a warning similar to mixed content. When moused over shows "could not check information". ONLY TRUE IN DEV/BETA CHANNEL, not stable at this time

Chrome 10 Screenshots

Chrome 10 standard EV presentation
Chrome 10 EV with default settings and the OCSP responder returning 500:
Chrome 10 with OS X's "Require" turned on for EV:

OVDoes not check by defaultEVChecks and if no response/invalid response removes EV presentation, making it look like OV

Safari Mac OS X Screenshots

Safari 5 standard EV presentation
Safari 5 EV with OCSP responder returning 500
Safari 5 EV with OS level OCSP/CRL turned to require and OCSP/CRL returning 500

OVChecks OCSP/CRL and removes the encrypted connection indicator if response fails.EVChecks OCSP/CRL and removes the encrypted connection indicator if response fails.

Opera 11 standard EV presentation

Opera 11 EV with OCSP responder returning 500

Opera 11 Additional Detail

OVChecks CRL (no OCSP support) but if request gets no response/invalid response no error/UI change occursEVChecks CRL (no OCSP support) but if request gets no response/invalid response no error/UI change occurs (EV presentation is NOT removed)

IE XP Screenshots

IE8 EV presentation on XP

OVChecks OCSP (with CRL fallback) but if request gets no response/invalid response no error/UI change occursEVChecks OCSP (with CRL fallback) but if request gets no response/invalid response no error/UI change occurs (EV presentation is NOT removed)

IE Win7 Screenshots

IE9 EV presentation on Windows 7

Solutions?

Revocation, while not broken in principle, does not work in practice. Browsers typically don't check it, and when they do they don't hard fail on no/broken response. So what do we do?

Browsers can't afford to hard fail unless revocation infrastructure is reliable, but hard fails on error are the only way to guarantee user security. This ideally means revocation data should be decentralized as much as possible¹²

One feasible (but not near-term) solution to partial decentralization is OCSP stapling. OCSP stapling has the server make requests to the OCSP responder, cache the response, then serve it to the client as part of the initial handshake. This lowers latency for the browser and is secure since the response is signed to prevent tampering at the server side; but OCSP stapling is not widely available at this time. Most web server software does not support it¹³ and browsers may not have it implemented. Additionally, OCSP stapling supports only end entity (also known as leaf) certificates and can't staple responses for intermediate certificates¹⁴.

In the near-term there are several ways browsers and CAs could begin to mitigate this security issue and improve the utility of revocation. These "fixes" all come with an attendant set of problems, but in the wake of recent events we should seriously consider whether the problems created by "fixing" revocation outweigh the advantage gained.

• Check CRL/OCSP for all certificate types
• In conjunction with the above, to prevent serious issues don't throw errors but degrade UI to non-SSL when unable to fetch revocation status
• Instead of the above, hard fail and shame any non-performant CAs into improving their revocation infrastructure

In concert with this CAs would need to discuss metrics with the browser makers to determine the load (and distribution of that load worldwide) that will be experienced as well as acceptable response times, et cetera.

Another performance optimization could be found in "prefetching". At the moment OCSP and CRL checks are blocking on HTTPS connections for security reasons. To speed things up without compromising security browsers could potentially fetch data that didn't include identifiable information¹⁵ and then hold onto that data until the response came back. If it was invalid/revoked then the data can be dropped without ever being rendered/executed. This lets the browser parallelize some aspects of the connection and speed up the browsing experience without sacrificing significant security. Of course, this would only be useful in the most basic case of "GET /" without a session.

Non-Browser Utilization of SSL

This entire discussion has been concerned with the way web browsers handle HTTPS, but there are numerous other applications that make use of SSL (and even HTTPS) that are not web browsers. Email clients, mobile apps, APIs such as Java's HttpURLConnection or Ruby's Net::HTTP, command line clients like curl, and many more all rely on SSL and the vast majority do not check revocation. These should not be forgotten in the push towards greater security.

Footnotes