Heartbleed: What programs are 'critical infrastructure'?

Heartbleed: What programs are 'critical infrastructure'?

Summary: Bugs don't often get more severe than Heartbleed and OpenSSL, the affected code, is about as critical a library as there is on the Internet. Does it need special treatment?

TOPICS: Security

Tuesday was supposed to be about Windows XP, and basically it was, but there was another event which was of greater security significance: Heartbleed.


Heartbleed is a catastrophic bug in OpenSSL, a software library of great significance, used by almost everyone (except Microsoft) for their SSL/TLS code. It's a truism of cryptographic applications programming that you don't write your own actual crypto code because it's so important and really hard to do right; you trust the operating system's library or some other well-established library, and in the real world that means, as a practical matter, either Windows Cryptographic API or OpenSSL (although there are others).

Obviously it's of critical importance that this code be as correct and unexploitable as possible. To whom is it important? To everyone with an interest in private communications. Heartbleed makes a mockery of this protection by exposing memory in the server, including private keys, to attackers. It has existed since December 31, 2011 and been in wide, and growing. use since the release of OpenSSL 1.0.1 on March 14, 2012.

If so many users, in government, private industry, non-profits, all over, are relying on this code, perhaps the security of it can't be left purely in the hands of the 15 men of the OpenSSL development team.

It's interesting that Heartbleed came out of a new feature added to TLS, the Heartbeat Extension. Last night I observed a Twitter fight between two security experts I follow (Dan Kaminsky and Thomas Ptacek) over whether it was a good idea to add the Heartbeat Extension to OpenSSL. The problem is in the implementation, not the protocol, but with such critical code (one of them argued) spurious features should not be added.

Is the Heartbeat extension spurious? That was the heart of the argument. The Heartbeat allows, as the RFC says, "...the usage of keep-alive functionality without performing a renegotiation..." With all due respect to @tqbf, clearly this is of value, if not essential to the core protocol. The problem wasn't including the Heartbeat, it was including it without sufficient scrutiny.

In fairness to the OpenSSL team, I don't know how much scrutiny they subject their code to. But, even so, it can't ever be enough. One of the suggestions that @dakami makes is "I believe strongly in federally funded source monitoring of important projects. Social good, social burden."

Now this is thought provoking. Even as a relatively libertarian type, I think the government has always had a proper role in the establishment and maintenance (including security) of critical standards. (It's even in the Constitution, Article I Section 8: "The Congress shall have Power To... fix the Standard of Weights and Measures...") It's not much of a stretch in my mind to extend this power from actual standards, with which NIST is concerned, to critical implementations of software standards.

The system could work through grants to some outside responsible organization, perhaps even a private company, to perform audits on software determined by the responsible government authority (it could be NIST as well) to be critical.

There's never enough money to go around for these things, but I'd suggest that the security of this and certain other code is critical enough to private industry that they could be induced to make contributions to a fund for it. Any such audit work should be made completely public of course. As Matthew Green, who teaches cryptography at Johns Hopkins, puts it, "The best contribution would be for the 5 biggest tech companies to each pledge 1 dev for 2 years. No strings." When you put it that way it doesn't sound like a lot.

Many private companies already perform security audits on their own code or on open source components that they use. Apparently it's not enough and it never really can be enough. (Did anyone already do an audit of the OpenSSL TLS Heartbeat implementation and miss Heartbleed? That would be embarrassing.)

What other programs are critical infrastructure? Sound off below.

Topic: Security

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
  • M$ subverted it

    by not providing funding for it.
    more reasons to stick with pure FOSS.
    LlNUX Geek
    • Directly from his mothers basement for a limited

      performance it's the Geek who is so out there he's a laugh riot!
      • Ad Hominem Much?

        So instead of challenging the statement you attack the commenter instead?

        It should be pointed out that, in this case, M$ has no responsibility to support a code base they don't use. If it turned out that there were portions of OpenSSL in the M$ code then that would be a different discussion.
        • But he is a troll

          The response was correct. And LG's post wasn't particularly enlightening.
          John L. Ries
        • Anyone who refers to Microsoft as M$ has demonstrated they're...

          ...unable to hold a rational discussion.
          • That would be an over-generalization

            But derisive language should indeed be flagged, even if the post is otherwise intelligent.
            John L. Ries
          • Are you not a capitalist?

            Why would that be after all Microsoft is a corporation. It has no existence except to use it customers to the greatest extent possible for profit. M$ is correct. For the money and how.
    • BTW - Guess you

      didn't read the article this is FOSS... what a jack wagon
      • Guess You Didn't Read The Comment

        The commenter was claiming M$ has a responsibility to support the FOSS project. I disagree since M$ relies upon their own code for this functionality. But that is far from claiming that M$ code failed.
        • Guess You haven't read any his comments

          everything, and I do mean everything, is always either MS's fault, or Apple (in a pinch).

          He's trolling for the sake of trolling.

          But I'm wondering if your bias (come on "M$"? Who uses the dollar sign anymore? That's so 10th grade) kind of blinded you from that.

          But you know how it goes - when there's FOSS issue, it's never G$$gle's fault...
          • What case can you make...

            ...that Heartbleed was Google's fault? I even seem to recall that it was Google that reported the bug to the OpenSSL developers.
            John L. Ries
    • Why should Microsoft fund it ?

      They have their own implementation.

      They have no responsiblity in this whatsoever.

      Sticking with pure FOSS isn't any better as this sage clearly shows.
      • FOSS has nothing to do with this

        ANY software is going to have a bug or two that make it out, I don't care how much money and time you throw at it.

        The TRUTH is that this bug was NOT A SURPRISE, and was in the process of being PROPERLY REVIEWED, and a fix was just days away from being released in general. The REAL issue that this article completely ignores is that Cloudflare irresponsibly exposed this bug before the fixes were ready to be deployed in a general manner. This created a panic, both for those that could be affected by it, and by those that want to exploit it.

        Cloudflare needs some hard scrutiny put on them, because I wonder if they didn't do this to get some attention: "Hey, we fixed this massive hole before anybody else! See you need to use our service!"
        Technical John
    • Stick with FOSS

      Ummm - I may be wrong but isn't OpenSSL "pure FOSS"?

      Microsoft has their own implementation which is not subject to this issue - why should they pay for a second implementation?
      • MSFollower: "isn't OpenSSL "pure FOSS"?"

        That depends on one's beliefs. OpenSSL wasn't pure enough for Richard Stallman which is why GNU created GnuTLS.
        Rabid Howler Monkey
        • Yes they did

          To be honest GNUTLS doesn't play along with many other ssl technologies (including servers running openssl).

          I actually used exim-heavy from debian which is build using GNUTLS, oh boy, tls didn't work with any third party smtp server I tried.

          Downloaded exim, recompiled it with openssl, and voila all works.
        • Richard Stallman boarders on irrational when it comes to OSS.

          Too idealistic lacking almost any form of pragmatism.
          • He has some

            That's why, for example, the LGPL exists, and why the run time libraries distributed with GNU compilers are distributed under a "runtime execption" to the GPL.

            But he's very clear about where he wants to go, and acts accordingly.
            John L. Ries
          • Idealism and Pragmatism

            Properly considered, they actually complement each other. Idealism is about where you're trying to go; pragmatism is about how you get there. The trick is in making sure that one's pragmatic decisions actually get one closer to the destination than one would otherwise get.

            One doesn't want to compromise one's principles (and valid compromises partially further the goals of all parties), but hardlining almost never accomplishes the desired ends.
            John L. Ries
        • That would be a licensing issue

          OpenSSL is part of the OpenBSD project and per policy, is distributed under the same BSD-style license other OpenBSD code is. RMS naturally prefers the GPL and LGPL. But OpenSSL qualifies as free software even according to the FSF's exacting standards, and there are other important non-copylefted programs and libraries the GNU people have never bothered to rewrite (like the X Window System, for example), so I don't know why the FSF bothered.
          John L. Ries