The recent Heartbleed issue has reawakened interest in SSL certificate revocation (see Adam Langley’s blog, Larry Seltzer’s articles here and here, and Steve Gibson’s web pages)
Several years ago, the CA Browser Forum convened a special Revocation Working Group to explore issues and solutions. Leading CAs were actively involved in that group, and many of them invested in moving their OCSP responders to high-performance, high-availability Content Delivery Networks (CDNs) to respond to browser vendors’ requests for increased performance and reliability.
Google was part of the Revocation Working Group and announced CRLSets to that group and the wider CA Browser Forum. CAs were disappointed that Chrome wouldn’t actively retrieve OCSP responses from them, but we were under the impression that CRLSets would include most revoked certificates. Adam did ask CAs to help CRLSets by telling Google about important revocations, and CAs largely complied, for example, when the CA had to revoke intermediate certificates. But CAs have no reliable way of knowing which end-entity certificate revocations are important, since certificate owners don’t reliably tell CAs whether or not the revocation is important. Many CAs allow the customer to choose from a list of “revocation reasons”, but just as companies are hesitant to reveal that they’ve suffered a security breach, it’s assumed that they are hesitant to tell the CA that their private key had been compromised (this would constitute an important revocation).
As a result, end users and browsers have no way to determine whether a certificate was revoked because of the server’s loss of control over the key, fraudulent activity by the server administrator, the presence of malware on site, or simply out of an abundance of caution. Heartbleed is a perfect example of why revocation is important even without identified key compromise. No one can say for certain that their server’s private key was compromised. Most of the revocations that have occurred are going on CRLs for “business reasons” (as Adam defines it) and not picked up by CRLSets.
It’s now clear that CRLSets are simply a blacklist of high-profile revoked certificates. Other browsers have similar blacklists, and these can be effective at times (for example, to indicate revocation of an intermediate certificate that may be several years old and does not contain an OCSP pointer). But they’re not a substitute for OCSP checking of end-entity certificates.
Google moved away from supporting OCSP without adequately informing Chrome users of this fact. Although IE and Safari also soft-fail if an OCSP response is not received, those browsers still use OCSP by default. The engineers creating those browsers apparently have not concluded that OCSP is broken. Even if revocation checking by OCSP isn’t 100 percent accurate, it can still protect a high percentage of users who navigate to a site with a revoked certificate and receive an OCSP response indicating revocation. Turning off revocation checking for everyone means that no one is protected.
All browsers compete on speed and performance, and OCSP checking can slow page loading. We think many browser users would tradeoff a small performance hit for increased confidence in the authenticity of the web site.
Revocation is a very complex issue, with lots of room for debate. Reasonable people can disagree on the effectiveness of using OCSP. The CASC agrees that OCSP Stapling, and putting OCSP Must-Staple extensions in certificates, is one of the best solutions to address many issues with revocation at this time. But until that happens, we oppose browsers removing (non-stapled) OCSP checks.
