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.
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 revoked1 along with a notBefore and notAfter date for the CRL itself. Each CRL is signed by the root2 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 CA3 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 serial4 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 certificate5.
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 repository9. 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 certificates10.
Domain validated certificates are by far the most popular (and cheapest) certificate available today. Their vetting methods vary by CA11, 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 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.
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.
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 | |
|---|---|
| DV | Checks OCSP if AIA is present, no CRL check |
| Can turn on security.OCSP.require to true, but if the cert has no OCSP embedded it does not check CRL and proceeds without issue. Firefox will also check intermediates on DV/OV/EV if an OCSP AIA is present but does not provide UI feedback if they fail except the EV presentation removal | |
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 | |
|---|---|
| DV | Does not check by default on Mac/Windows (Linux unknown) |
| Default checking same as Safari on Mac (controlled by parent OS prefs). On Windows presumably mediated by schannel and NSS on linux. Chrome checks the entire chain for EV (and may do it for others if the checks are enabled at the OS level) | |
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 | |
|---|---|
| DV | Does not check by default |
| Controlled by Keychain Access (~/Library/Preferences/com.apple.security.revocation.plist). Hold option to select require for all certs on OCSP or CRL. Requiring (or even best attempt) can cause odd behavior with some other programs. This may be due to extremely large CRLs or other improper deployment of revocation infrastructure. For example, Apple's Worldwide Developer Relations CA (WWDRCA) has a 10MB CRL containing over 243,000 entries. Safari checks the entire chain for EV (and will do so for the others if checks are enabled) | |
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 | |
|---|---|
| DV | Checks OCSP/CRL and removes the encrypted connection indicator if response fails. |
| Opera is the most aggressive of the major browsers. The connection will be labeled unencrypted if revocation checks fail. Opera checks the entire chain if CDP/AIA is present. | |
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)
| Internet Explorer 7/8 (Windows XP) | |
|---|---|
| DV | Checks CRL (no OCSP support) but if request gets no response/invalid response no error/UI change occurs |
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)
| Internet Explorer 8/9 (Windows 7) | |
|---|---|
| DV | Checks OCSP (with CRL fallback) but if request gets no response/invalid response no error/UI change occurs |
IE9 EV presentation on Windows 7
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 possible12
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 it13 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 certificates14.
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.
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 information15 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.
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.