Chrome does certificate revocation better

Chrome does certificate revocation better

Summary: There's a dirty little industry secret: The classic methods of certificate revocation don't really work. That's why Google Chrome doesn't do certificate revocation checking the normal way.

TOPICS: Security, Google

Everyone's talking about it: The Great Certificate Revocation Storm of 2014. Because of the Heartbleed bug, a very large number of SSL/TLS web sites need to revoke and reissue their certificates.

The circumstances create the equivalent of several major Internet traffic jams. Things will be slower for everyone... except maybe Google Chrome users. They do things differently. (While we're on the subject, there are many articles out there telling users to turn on certificate revocation checking in Chrome. Don't. Bad idea. More about this below.)

Here's how SSL/TLS is supposed to work for site authentication: Browsers and other user-agents are supposed to check, when they get certificates from sites, whether those certificates have been revoked or are still valid. There are two methods for checking: Certificate Revocation Lists (CRLs), which are simple lists of serial numbers of certificates that have been revoked, provided by each Certificate Authority (CA); and a communication protocol called Online Certificate Status Protocol (OCSP), which allows a system to check with a CA for the status of a single certificate without pulling the entire CRL, which, as we'll see, can become quite large.

The other day, certificate authority CRL grew to approximately 4.7MB in size from approximately 22KB because CloudFlare, a Content Delivery Network (CDN) that uses GlobalSign as their primary CA partner, decided to revoke and reissue all their customer certificates. That was about 50,000 unique certificate revocations at once, and you can bet it's not the last such mass-change in the near-term.

Now imagine that users all over the Internet are checking for certificate revocation and having to pull a file that's many MB in size. It can be cached to a point, but we can also assume that CRLs are more volatile than they have usually been. This all adds up to the CAs turning into a major performance bottleneck on the Internet for the near future. Even OCSP can be effectively cached through a technique called OCSP stapling, in which the certificate authority includes the OCSP response with the certificates.

And in practice, it's not practical to be completely scrupulous about revocation checking. For one thing, revocation checks can fail for many different reasons and you can't treat the failure as a finding of revocation, so such failures are generally ignored by browsers; this is called a "soft fail."

The harsh, but accurate conclusion from this is that certificate revocation checking doesn't actually work. Any actor in a position to intercept your traffic (which is why they would want to decrypt it) is also in a position to cause revocation checking to fail. Since the browser will just punt when this happens, it means that revocation checking does nothing; the man in the middle can use a revoked certificate if he wants to — any browser will let him get away with it. I don't want to claim that such circumstances are likely or easy to create, but a determined actor with resources is not prevented by the technology from accomplishing them.

For this and other reasons, Google decided in 2012 to default Chrome not to check for certificate revocation on non-EV certificates. (EV or Extended Validation certificates are more expensive certificates with more stringent buyer verification and browser behavior rules.) Instead, Google uses their Chrome update mechanism to send batches of serial numbers of revoked certificates which it constantly gathers by crawling Certificate Authorities.


Google's approach trades off some precision, in that the CRLSet may be old compared to the contents of the current CRL or the response of an OCSP request, but in exchange the user gains some performance and reliability. As a Google spokesperson said to me, "...[W]hen we identify a bad cert, we update our revocation list, and Chrome users are automatically protected. CRLSet updates occur at least daily, which is significantly faster than most OCSP validity periods."

Even so, there are many, like Netcraft, who have been telling Chrome users to turn on certificate revocation checking. But Google's Adam Langley shows that this is a big mistake, for the reasons already stated, i.e., that revocation is broken:

    That's why I claim that online revocation checking is useless — because it doesn't stop attacks. Turning it on does nothing but slow things down. You can tell when something is security theater because you need some absurdly specific situation in order for it to be useful.

I don't know many independent observers (independent meaning not a CA) who would defend the current revocation system. When faced with the facts of the post-Heartbleed world it looks like a poorly thought-out hack. Most of us see the hack and complain about it. Google saw the hack and did something about it. Something imperfect, but something worthwhile.

The weaknesses of the certificate revocation process aren't completely news to those who follow these matters, but now it's impossible to claim that the system works. I only wish I had seen a decent idea for something to replace it. Langley speculates about a solution involving short-lived certificates or mandatory OCSP, which effectively amounts to the same thing. But in fact, there are no solid plans out there to make a better system. In the meantime, many security claims on the Internet are exaggerated.

Topics: Security, Google

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


Log in or register to join the discussion
  • Short term certificates...

    are equivalent to how Kerberos handles credentials.

    They expire quickly, making revocation nearly unnecessary.

    The thing used in ADDITION to credentials is having to get a credential from a server using a limited time principle (good only for getting additional credentials...) And those added credentials are limited to the remaining time of the principle credential, or have deliberately more limited times...

    On top of that, keys issued to servers also have a limited time (I've seen 30 to 90 days) where the server must get new credentials. To allow for continuous operations two credentials are allowed to overlap in time.

    Revoking a credential prevents users from obtaining keys (principle tickets or service tickets), it prevents servers from getting new keys... and it stops the issuing of credentials (service tickets) to users to use to contact servers...

    PKI has never been scalable - the lifetime of certs are WAY too long, and revocation impossible to support.

    I used to support a standalone internal PKI. The root certificate was deliberately limited in use to one year. Each server had a short list of allowed certificates (the inverse of the revocation list problem). Suitable for internal use only.

    OSCP is too slow to use. Proper use would require each entry in the certificate chain to be checked... and that would potentially be against a different OSCP server at each link. Most chains are 3 to 5 links long. Since you may be getting 30-40 URL references (each potentially to a different ad server) that would be (worst case) 90 to 120 DNS lookups, plus the OSCP query... per web page. Now local caching would help a lot and reduce the worst case to only occurring on the first page viewed... but then you have the problem of knowing when to flush the cache.
    • So you agree?

      In light of everything you say, and for lack of a better idea, CRLSets seem like a good compromise, no? Obviously a Kerberos-like system can't scale to Internet-size
      • CRL sets are likely the only solution... and not "best"...

        Kerberos can scale to very large sets - the largest I have directly worked with would be about 20,000... But with the cross realm capability, it should be able to scale to millions.

        The scaling problem isn't technical - it is political. Microsofts passport was one attempt - but due to MS demand to control everything, didn't work worth a crap.
    • OSCP implementation

      if the OSCP implementation were changed it could be much faster though. To support my argument ill point you back to Google Search. If you haven't noticed Google publishes its search times which are typically
      • No, I don't think so.

        You would have to have at least one OSCP server for each source of certificates - and like the DNS system, you would need multiple.

        Second, you would have to provide an infinite lifetime cache (Well, it would have to last at least as long as the signing certificate lifetime - which in most cases is as long as 30 years).
    • kerberos issues

      Tickets, not certificates. Now when it comes to webservers issuing certificates with a short expiration time wouldn't be feasible, as it would greatly increase administration efforts.

      When using certificates for authentication for say vpn access or access to a wireless access point, one could use certificates with a much shorter expiration time, providing one uses auto-enrollment, so that getting new certificates can happen without human intervention.

      Of course this still leads to problems, especially if you have people that work on a consultant basis, that hardly ever go onto the office or even make a vpn connection now and then. For these people we need to manually issue certificates as they are quite likely to not connect for months on end.
  • many security claims on the Internet are exaggerated.

    Not sure which way you meant that... but
    I think we might find that it applies no mater which way you meant it.

    Security gurus and thus departments parroting what they have been told exaggerate threats and use vague accusations (mostly as a means to wield power) demanding someone else do work without offering any solutions.

    Security mechanisms like certificates and even most protocols suffer from less than perfect design and implementation or anything near good enough leaving vulnerabilities to be discovered and exploited.

    Security Threats and vulnerabilities too are often exaggerated... never let a good crises go to waste...

    It seems the only security is security by obscurity ironic that security people rail against it so much. Encryption is nothing more than obscuring data in a way to hopefully make it obscure long enough to not matter once its been deciphered. All security mechanisms have been/can be defeated with the right knowledge and opportunity.

    The Internet is built on technology that was never designed for security, somehow we keep limping along by using the Band-Aid approach. Google's stab at the revocation problem leans more toward trading off security for speed leaving a timing hole. As someone famously stated all timing holes are infinite. Blocking or interfering with the Google update leaves you stuck in time. Now who would do that... the same people that defeat antivirus software to make you vulnerable to their next attack.

    Help us out here IETF and quicken your pace while doing it.
    • The problem is not encryption.

      The problem is "trust".

      Setting up encryption is relatively trivial - but how do you trust the target of your connection? THAT is the problem. Not the encryption.

      PKI is based on trusting a certificate distributor to validate the ownership of a specific certificate. The speed depends on how you validate the ownership...

      In the case of PKI you have a copy of the public key for the certificate issuer you "trust". To validate a certificate chain requires to check each certificate (as when you go to look up a domain name - you start at the root....) and check each link in the chain. And for each link you have to make one or more lookups (some OSCP servers may not be reachable, so you have to try a second). Unlike DNS, where you can skip the middle of the chain if you already have it, you have to check EACH TIME for revocation.

      And that makes it rather slow no matter what you do... unless you just don't check it at all - and depend on expiration only, or having a a local list...
      • I dont agree with your conclusion on PKI

        Encryption and trust are separate issues both are needed.

        Weak encryption or a flawed implementation becomes easily defeated. That is the reality with most things.

        I'm 100% certain a fast reliable OSCP type service could be implemented. I cannot go into details here... but the requirements you stated are not necessary... with the proper design and implementation.
  • I have been using OSCP

    Since 2008, it is not like this is new. Google remark about Oscp validity is bullocks, as the whole point of Oscp is that it queries the CA on behalf of the client. The crl updates are never going to be more recent at Google, for obvious reasons.
  • As an example, email (again)

    Does this mean that if a email server is patched for the OpenSSL Heartbleed vulnerability, one is safer using an POP/IMAP email client than a web browser with https? Or can an email client be spoofed the same way as a web browser?
    Rabid Howler Monkey
  • hey

    this have been mentioned in grc security now podcast 454, around the 1:50:00 mark
    • Yes, mentioned in Security Now episode 454

      And basically blown to pieces.
      It's obvious really.
      Deciding not to do checks can IN NO WAY be described as doing it better.
      • See also:
  • A simple test desconstruct what this article claims.

    A simple test.

    With "Check for server certificate revocation" unchecked, under Mac OS X, and Google's Chrome 35.0.1916.114 (latest version), go to, and you go directly to the website with the certificate shown as valid, while it is already revoked, though. With the "Check for server certificate revocation", it is blocked.

    Under Windows, it looks like the CRLSet is updated and it aborts the connection to the website in both scenarios, with either the "Check for server certificate revocation" checked or unchecked.

    Under Android Platform, it is worst than in Mac OS X, the user feels like in a safer place and there is no option to turn the verification on.

    It is clear that the Google's approach is not so efficient as it claims to be.

    After security now 454 episode, I've changed back my default browser to Firefox.

    Thanks Steve!