Internet slowed by Heartbleed identity crisis

Internet slowed by Heartbleed identity crisis

Summary: [UPDATED] Millions of SSL certificates need to be revoked and reissued. The Internet and the PKI were not designed for this. Congestion will reign.

SHARE:
TOPICS: Security
10

Warning: Unscheduled construction will slow traffic on the Internet for an undetermined period. Plan extra time for communication.

Many bad things will happen because of Heartbleed. One which will affect nearly everyone is a general slowing of performance owing to the need to revoke and reissue millions of SSL/TLS digital certificates and keys. The volume of such revocations has been increasing in the days since Heartbleed was announced to the world.

[UPDATE: A new report from the Internet Storm Center shows a spike of over 50,000 unique revocations from a single CRL from Globalsign.]

Netcraft.heartbleed-revocations5
source: Netcraft

Netcraft, a research firm which monitors web sites and certificates world-wide says that the number of certificate revocations is at 80,000 and has merely begun. Very large SSL providers like Akamai are planning mass-revocations of customer certificates.

SSL/TLS certificates are used by Internet parties to prove their identity of each other. They are used for much more than secure web sites: Many VPNs rely on SSL for clients and servers to prove identity to each other.

When a certificate becomes untrustworthy and is revoked, a unique identifier for the certificate is added to a file called a CRL (Certificate Revocation List). Each certificate contains a field for the specific CRL to check to see if it is revoked.

Chrome.doesnt.check.revocation

There are two problems with this process: CRLs can grow to an unwieldy size, which creates a performance problem both for the client and server; and many clients aren't very good about checking for revocation. Consider the nearby image, a screen grab from Google Chrome Settings: By default, perhaps as a performance measure, Chrome does not check for certificate revocation. In fact, these are just two of the problems with certificate revocation. In the real world it fails in many other ways.

The graph below from the Internet Storm Center shows a measure of CRL growth. It's actually not clear whether the graph, which shows "CRL counts of sixteen different CA's since April 1, 2014," shows the size of CRLs or the number of them, or whether it's a measure of growth per day. But it's certainly growing. Netcraft says that if all the certificates affected by Heartbleed were to be revoked, CRLs would grow by about 35%.

ISC.CRL.Counts

Because of the limitations of CRLs, a new standard called OCSP (Online Certificate Status Protocol) was developed years ago so that a client could check with the CA for the status of a single certificate. In normal cases, where checks are done one at a time, this approach saves a lot of network bandwidth. At a time when large numbers of revocations are being performed, reliance on OCSP can be a large burden on the CA systems. Note: Firefox no longer supports CRLs at all, relying entirely on OCSP.

Topic: Security

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

Talkback

10 comments
Log in or register to join the discussion
  • That isn't very much in the way of CRLs

    There are millions of certificates out there. The government alone has issued something over 15 million...

    PKI was never designed for use the way people are trying to use it...

    CRLs never really worked - querying a CRL is too slow, so nobody really does it.

    Instead they depend on the certificate expiring...
    jessepollard
  • OCSP isn't that new - it has been around since 1999.

    Didn't work then, won't work now.

    It is OK for queries about a single certificate... but is useless for checking a certificate chain.

    Too slow. It would make loading a typical web page look like using a 300 baud serial line for a network.
    jessepollard
  • Much of the Internet is based on technology that wasnt designed for its use

    That makes us less secure and more vulnerable every day. It should be fixed before something really bad happens. The excuses are wearing thin.
    greywolf7
    • Which is why IPsec should have been in use for years.

      Easier to deploy, and maintain.
      jessepollard
      • But OpenIPSEC would create the exact same problem

        A hole in the IPSEC heartbeat would leak the keys and private data and force certificate revocations. :-)
        greywolf7
      • easy?

        I would call IPSec many things, including "good," but "easy?"
        larry@...
  • certificate authorities

    Cert Authorities must be happy to be making the big $$ at a time like this!
    Radomir Wojcik
    • JohnA

      I've been told by some going through the process that some are issuing them free of charge...
      TechieJohn2
  • Meanwhile...

    ...back in Central Dispatch, no evidence has been found that claims that this hole has been exploited for criminal gain.
    harry_dyke
  • Vulnerable

    70% of companies of all sizes lack the security expertise to deal with an attack if one were to occur, and most of those companies have little to zero protection for networks, email, or consumer devices. Some good data (and laughs) here... https://www.youtube.com/watch?v=J2At0_9Ki3E
    chrisanton