It was a dark and stormy night, more than a decade ago, in a dimly lit listserv of the CA/Browser Forum.
The shadowy forces of the Public Key Infrastructure gathered to make a fateful decision: Certificate Revocation Lists (CRLs) had to be stopped. They had grown too large, threatening the bandwidth and storage budgets of the great Certificate Authorities (CAs). Seeing no way to contain the CRL threat, the engineers representing the CA/Browser Forum members took a drastic step: They made CRL support optional.
[cue ominous music]
Murder, most foul
Formally they had not killed CRLs, but the effect was still murder most foul. A leading browser deprecated support for them. And new and powerful CAs never bothered with life support for CRLs.
As the carcass of CRLs lay decomposing, a new revocation function took its place: Online Certificate Status Protocol (OCSP), which is an interactive function by which CAs return the status of a specific certificate.
The relative merits of the new trade-off were never clear to some. Instead of having to serve large amounts of static data, CAs would have to respond to large numbers of requests for small amounts of data.
To lessen the load on CA OCSP services, the specification allows clients (usually web browsers) to cache results for up to a week. In other words, a browser might rely on a certificate that had been revoked up to a week earlier, and that would be just fine with the specification.
OCSP also compromises privacy: to check for revocation, you have to tell the CA what websites you are visiting, by asking if that site’s certificates have been revoked. Is the CA obligated to protect your privacy? Would you trust them even if they were?
The horrible truth about revocation
But revocation these days isn’t just insecure or inadequate. It flat-out doesn’t work. Here’s why.
Consider what happens when the system fails: What if the CA infrastructure is unavailable or if it just doesn’t respond to a revocation check in a reasonable amount of time? Not showing the user the web page is not acceptable, so the browser could do what is euphemistically called a “soft fail,” meaning that it will just proceed without the revocation check.
It wasn’t long before browser authors realized how phony it all was, and so Chrome long ago stopped doing revocation checks at all. Explaining the situation more than ten years ago, Google TLS wiz Adam Lang said soft fails were like “a seatbelt that snaps when you crash.”
More than five years ago, security researcher Scott Helme opined on the problem of certificate revocation. He described some proprietary and standards-ish solutions, such as Chrome CRLsets and Firefox CRLite - both curated lists of high-value CRLs; and OCSP Stapling, in which the web server does the OCSP request for the user and includes the response with the page.
Current versions of Chrome provide no setting for turning CRL or OCSP checks on or off. They appear only to use CRLSets. Based on the current settings screen, it appears that Firefox still does OCSP checks (presumably if CRLite checks fail), but you can turn them off if you want.
It CAN be done right
Public web servers can get away with this level of service, but in enterprise application development, surely TLS revocation is taken seriously, checked when appropriate, and errors flagged, right?
Right, says Mark Sanders, Senior Solution Architect at Venafi. “In normal enterprise environments, they will either use CRLs or OCSP. They will use this for their internal PKI (typically a Microsoft PKI) as well as public certificates (what their apps and employees will utilize when they go external).”
The fix is in
Recently, the aforementioned leading browser (Mozilla) and powerful CA (Let’s Encrypt), among others, decided that CRLs are what is needed to fix revocation. And just like that CRLs were back from the dead. A September Let’s Encrypt blog described a new proposal, which they call Browser-Summarized CRLs.
"Rather than having each user’s browser download large CRLs when they want to check revocation, the browser vendor downloads the CRLs centrally. They process the CRLs into a smaller format such as a Bloom filter, then push the new compressed object to all of the installed browser instances using pre-existing rapid update mechanisms. Firefox, for example, is pushing updates as quickly as every 6 hours."
CRL data is the kind that should compress readily. The idea was promising enough that, as of October 1, 2022, the Apple and Mozilla root certificate programs both require the use of CRLs by participating CAs.
Do Browser-Summarized CRLs hold any promise for non-browser enterprise applications? Sanders says “Possibly. I think it’s early. AND there are lots of moving parts to the implementation.”