OpenSSL describes its own sad state of affairs

OpenSSL describes its own sad state of affairs

Summary: On the road to recovery from the devastation of Heartbleed, the OpenSSL project has made a searching and fearless moral inventory of itself.

TOPICS: Security

It's almost three months since the Heartbleed bug became public, after which the sad state of OpenSSL, the overwhelmingly dominant TLS/SSL library on the Internet, became common knowledge. Now the OpenSSL project has released a roadmap document describing the problems with the software and their plans to address them.

The list resembles lists made by many others in the wake of Heartbleed, meaning it pulls no punches. Nor does it pretend to promise quick progress: "Objectives and dates should be considered aspirational."

Crypto insiders had, for years, complained of the poor organization, unreadable code, almost complete lack of documentation, and other problems with OpenSSL. It was enough that the OpenBSD project decided to fork the OpenSSL code into a separate project they call LibreSSL.

Some of the issues raised in the document are:

  • The bug tracking system is overloaded with open tickets, a large proportion of which "...have been open for years." Some of these bugs have actually been fixed, but nobody bothered to record the fact in the system.
  • The documentation stinks. Not uniformly, but largely.
  • The complexity and poor organization of the code and lack of a consistent coding style make it quite difficult to maintain. The public API contains interfaces which should probably be private; fixing that now runs the risk of breaking applications.
  • There is no code review system. None.

From these problems, the project identifies objectives. New bug reports will receive an initial response within four working days, starting now. The backlog will be dealt with over time, perhaps by mass-closure of tickets. The public API will be documented within a year. APIs not meant to be public will not be documented or marked as deprecated.

Specific areas of the code, including memory management and the infamous FIPS support, will be reviewed and revised within a year or sooner. Plans for code review, audit, style guidelines and a release strategy will be developed within months.

Some serious thought will be put into which platforms to support. OpenSSL supports an excessive list of platforms. Many critics question the need for a Windows version, as it complicates the code and Windows developers largely use the operating system API.

It is, in a sense, inspiring to see the developers in charge lay bare the awful truth, but for developers that can only go so far. Can anyone feel good about committing to a project which looks itself over and sees all this? Remember, the goals and timetables are "aspirational."

The one thing I personally see which inspires some confidence is the only bolded non-title text in the document: "An important principle is that the priority and focus of effort will be on achieving these objectives over and above the delivery of new features." No sense growing the attack surface when what you have is such a disaster.

Nevertheless, the document also lists some new features which the team would like to add when the time is right. Some of these look like major gaps in the current software, such as IPv6 support, ARM support and multithreading.

It's true I don't have a good feeling about this project, but I do wish them well. When we look for software on the Internet which qualifies as "critical infrastructure," OpenSSL is at or near the top of the list. Let's hope they accomplish some of these goals before the next Heartbleed emerges.

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
  • not sure trying to *fix* it is even the right approach

    Sometimes its best to just start over and this is one of those times. Publish and API spec, get it approved by a standards body, write to that, release new code that's clean, clear, documented, tested and independently certified. Pull the old source and burn it. Anything short of that is a permanent black label on Open SSL and the open source community.
    • Who would run it?

      That catch is who would run it? We already have other commercial implementations. I can see all kinds of turf battles and forking going on if someone tried to implement the needed leadership.
      Buster Friendly
      • maybe kill it

        Maybe they should kill openssl and go with libressl, if things are that bad, it is better to just stop the pain and suffering and start new, with more control. Just a thought.
        • "No code review at all"

          Time to pull the plug on such kinda product.
        • premature

          One might have high hopes for Libressl, but they are nowhere near ready. For all we know at this point, OpenSSL might get their act together before LibreSS delivers usable code.
          • Doubtful

            The OpenBSD project removed a significant amount of code from LibreSSL. This was, in fact, the first thing that was done. Thus, there will be much less code for LibreSSL to deal with.
            Rabid Howler Monkey
          • Correction, meant to write:

            "The OpenBSD project removed a significant amount of code from LibreSSL immediately after forking it from OpenSSL."
            Rabid Howler Monkey
  • So open source is not the pancea.

    Who would have thought? Well, everyone except the open source fanbois. Only closed source code, especially that from Microsoft, could be a mess.
    • ye: "Who would have thought?"

      Anyone with a functioning brain. The OpenBSD project got serious with security starting in 1996. Very few, if any, open source projects have come close to OpenBSD's code auditing process. The POSSE (Portable Open Source Security Elements) Project tried to change this in 2001-2002, but not much came out of it outside of the OpenBSD Project:
      Rabid Howler Monkey
      • You see the problem with your response is...

        " The OpenBSD project got serious with security starting in 1996. Very few, if any, open source projects have come close to OpenBSD's code auditing process." is the PROCESS, not that fact OpenBSD is open source, which has led to secure code. That and the fact the default is a system which requires the end user to enable basic things in order to use the system.
        • You're making things up

          I neither stated nor implied that OpenBSD being open source has led to more secure code. It's code auditing process has led to more secure code.

          The OpenBSD project was launched in late 1995 and its security auditing process began in the Summer of 1996:

          This alone makes it clear that open source is insufficient.

          P.S. It's also interesting that the OpenBSD Project, operating on a shoestring budget, beat Microsoft with its SDL process by 5 years.
          Rabid Howler Monkey
          • And my comment you responded to was...

            ...the open source model doesn't make code more secure (which is what open source advocates state). Your response is pointless if you weren't trying to defend their position. With that said what was your point?
          • My comment made clear that it is the *process* that is important

            Your initial comment made no reference to *process*.

            In addition, my comment made it clear that some individuals and organizations perceived OpenSSL (along with other widely-used open source software) to be a security risk as far back as 2001 (i.e., the POSSE Project). This has received little attention from ZDNet and elsewhere in the media.
            Rabid Howler Monkey
          • In fairness to ZDNet, there's this piece about the POSSE Project from 2003


            "About $500,000 of the money went to several U.K. researchers to do a vulnerability analysis on OpenSSL, a widely used program for encrypting communications, especially to and from Web sites."
            Rabid Howler Monkey
        • The process is promoted...

 the fact that the project's leaders are not answerable to stockholders or a single corporate sponsor anxious to make money off of it. OpenBSD is a non-profit committed to providing a public good; and is free to act accordingly.
          John L. Ries
    • Perhaps not...

      ...but neither is the proprietary model; especially when combined with the speculator-centric business model that has been corporate orthodoxy for the past 30 years.
      John L. Ries
  • And what of GnuTLS?

    An open source (GPL) implementation of OpenSSL that defaults with Debian and Debian derivative distros such as Ubuntu and Linux Mint.

    Thus far, GnuTLS has not been "adopted" by the Linux Foundation CII.
    Rabid Howler Monkey
    • GnuTLS is worse

      Security researchers say not to touch GnuTSL due to its mishandling of binary data.
  • Within A Year?

    OpenBSD is fixing their version NOW. A year from now a completely refactored version -- LibreSSL -- will be up and running. Do they really expect that one year from now end users and developers will choose the old bloated version that was just fixed over the new, refactored, and audited version?

    I don't think the reality of their predicament has sunk into those running OpenSSL. Stick a fork in it; it's done.
  • Any large project requires good management and ongoing investment...

    ... in order to succeed. Some open source projects have done well gaining adoption (eg, GIMP, KeePass) and being maintained over time, but I believe this is more the exception than the rule.