Mozilla posts plan for certificate revocation checking

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.

SHARE:
TOPICS: Security, Browser
1
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

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

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

Talkback

1 comment
Log in or register to join the discussion
  • Google - the leader with the industry standard

    "Google was way out in front..."? CRLSets is a manually created hotchpotch of popular sites whose certificates have been revoked. If you stray from that small group while using Chrome, you are at risk. Google has gone so far as to remove the "check for certificate revocation" option that existed in Chrome!

    Steve Gibson created a page with a revoked certificate (https://revoked.grc.com/), so users could check whether their browser identified it. Most didn't, but Chrome was slower than the rest in picking up on it and when Google did so it turned out they had added the site to the CRLSets HEADER! A manual tweak to make sure their system still looked "solid". Gibson has since changed the certificate, and Google has not kept up.

    The solution is not Google's - they have been fighting the industry on this for years, and are on the wrong side. They need to accept the industry standard, and improve it from the inside. Yes, we need stapling. Yes, security will cause an infinitesimal slowdown in your surfing. Yes, it will make it safer than Google's current crapshoot.

    And we need our browsers to do a hard reject when they cannot locate the certificate status - which is the OCSP "risk" Adam Langley has been whining about for several years.
    Postulator