Mozilla posts plan for certificate revocation checking

Summary:The major software companies are rebelling against the established standards for revocation checking. Some new standards and some vendor hacks are replacing our current, broken system.

mozilla-posts-plan-for-certificate-revocation-checking

2014 seems to be the year of the great certificate revocation debate. Revocation was always a sore subject with cryptoheads, but the noise level on the issue shot up to 11 this spring with the news of the Heartbleed bug in OpenSSL.

As is often the case with TLS/SSL, Google was out front on this problem, but now Mozilla has posted a plan for improving certificate revocation checking in its software. The Mozilla approach tracks closely with Google's.

One of the disturbing implications of Heartbleed was that large numbers of secure web sites would have to revoke and reissue TLS/SSL certificates. 

There have always been reasons to lack confidence in the systems for certificate revocation in the PKI. There are two official, standards-based ways to check to see if a certificate has been revoked: the CRL or Certificate Revocation List, which is a static list of certificate serial numbers which can get very large and difficult to manage; and OCSP (Online Certificate Status Protocol), a method to perform a live query of the certificate authority for current status. Both methods have serious prolems.

OCSP was created to address the problems with CRLs, but OCSP can impose unacceptable latency on the page/resource request, so another standard was created: OCSP Stapling, in which an OCSP response is pre-packaged with the TLS web page and certificate, saving the time and trouble of communicating with the CA. But even this doesn't go far enough, as stapling is not mandatory; if a stapled response is not present and neither an OCSP nor CRL check work, browsers will still typically allow the page to load, because they don't consider the checks to be reliable enough to get in the way of the user. This is called a "soft fail."

So what to do? A number of methods have been proposed and are being implemented. First, there is a proposed extension to certificates called OCSP Must Staple. This extension says that if the certificate doesn't have a valid stapled OCSP response, the revocation check should fail. Mozilla explicitly endorses Must Staple and says they will advocate for it and implement it.

Google hasn't formally endorsed it, but Adam Langley, a key TLS engineer at Google, said in his personal blog that a scalable solution to the revocation problem could involve Must Staple. Must Staple also has the endorsement of the CASC (CA Security Council), an industry consortium of certificate authorities, including Symantec, GoDaddy and Comodo.

Special Feature

Next Generation Networks

The rising tides of big data, video, and cloud computing are driving tremendous demand for faster and more efficient networks. We delve into how things like software-defined networks (SDN) and new wireless technologies are enabling business transformation.

Google's other major move was to introduce CRLSets. These are Google-managed lists of revoked certificates that the company distributes to users through their existing update mechanism. Google curates this list so that only the "hot" certificates are included, ones that might matter for security. Mozilla will create a similar system called OneCRL

The combination of CRLSet/OneCRL and OCSP Must Staple could result in a robust enough revocation system. It has the disadvantage of not being simple, but this is security and cryptography we're talking about.

Where is Microsoft in all this? They haven't made a big deal of it, but they have built a CRLSet-like system into all Windows versions since Vista. It's an expansion on the much older Windows system for tracking revoked trusted root certificates. They store the list of certificates in a CTL or Certificate Trust List. Microsoft is silent on the value of Must Staple though.

Conceptually, Microsoft's CTL, Mozilla's OneCRL and Google's CRLSets are similar enough that it would be stupid for the companies not to share lists. And why stop there? Standardize the format as well. I suggest doing so through the CASC, which has also endorsed the CRLSet approach. Microsoft publishes the URL of their disallowed CTL.

There is one last technique that both Mozilla and Langley praise: short-lived certificates. If certificates had lifetimes measured in days rather than years, the revocation problem would take care of itself. This is the approach that DNSSEC takes and could be the basis of a secure system, but I assume it would greatly increase the administrative burden on certificate authorities. For that reason, put your money on hack solutions that are more complex in design, but simpler for CAs to execute.

Topics: Security, Browser

About

Larry Seltzer has long been a recognized expert in technology, with a focus on mobile technology and security in recent years. He was most recently Editorial Director of BYTE, Dark Reading and Network Computing at UBM Tech. Prior to that he spent over a decade consulting and writing on technology subjects, primarily in the area of sec... Full Bio

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Related Stories

The best of ZDNet, delivered

You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
Subscription failed.