OpenSSL's new security policy

The OpenSSL project is widely known due to its broad adoption as the SSL/TLS library of choice for open-source software—though, in April, it also became widely known because of a particularly vicious security vulnerability. To a large degree, the project weathered the storm, but the project has also undertaken some changes in the wake of the incident. The most recent is the adoption of a public security policy describing how issues of various kinds will be dealt with.

The "Heartbleed" vulnerability disclosed in April was, as has been discussed ad nauseam, a black eye for OpenSSL, but it also served as a wake-up call to the tech industry in general, especially to the large corporations that depend on OpenSSL's security for their own product lines. In May, the Linux Foundation (LF) announced a new program called the Core Infrastructure Initiative (CII) that was designed to financially support critical software projects like OpenSSL that have had a difficult time raising support for developers on their own. A number of major technology-industry players announced pledges of money to the CII cause and in May the LF announced that OpenSSL, OpenSSH, and Network Time Protocol (NTP) would be the first projects to receive funding.

OpenSSL, specifically, would be hiring two developers to work on the project full time, and Matt Green of the Open Crypto Audit Project would be paid to conduct a security audit of the codebase. The Economist's Schumpeter blog reported that the two CII-funded developers would be longtime contributors Stephen Henson and Andy Polyakov.

But putting paid developers to work is only one part of getting OpenSSL's house in order. In recent months, the project has taken a number of smaller steps to formalize—at least, publicly—its processes and procedures. On June 30, a roadmap was published, outlining several objectives the project intends to target in the coming weeks and months. Few of the entries would surprise free-software developers, as they enumerate common challenges: improving coding style, reducing the issue backlog, improving documentation, etc. Others include making some project-wide decisions, such as establishing a code-review policy and a platform strategy; processes that are underway.

Defining and publishing a security strategy was one of these roadmap items, and when the policy was announced on September 7, it was duly marked off of the list.

Policy

The security policy outlines OpenSSL's preferred procedure for outsiders to report possible vulnerabilities, how the project classifies vulnerabilities, and what the project's procedures are for publishing fixes and for notifying downstream projects and other organizations.

The procedure for reporting vulnerabilities, unsurprisingly, is to contact the project via email (optionally using PGP encryption). From there, if the OpenSSL team determines that there is a real vulnerability, it will (in private) classify the vulnerability as a low-, medium-, or high-severity issue. Low severity, the policy explains, applies to command-line utilities, unlikely configurations, and difficult-to-exploit issues like side-channel attacks. Medium severity encompasses client-side crashes, local flaws, and uncommon protocols. High severity is reserved for issues with common configurations that are likely to be exploitable.

These three classifications have ramifications for how OpenSSL will respond with its security fixes. A low-severity issue, according to the policy, will be fixed as soon as possible in the development branch, and "may be backported to older versions that are still getting updates". In either case, the project's vulnerabilities page and changelog will be updated when the fix is committed, but the fix will not necessarily trigger a new OpenSSL release.

Medium-severity issues, in contrast, will be kept private up until a new release is ready to be made. Nevertheless, new releases are expected to push out several such fixes at a time, rather than a new release being rolled out for any one such issue. The policy does not explicitly mention the backporting of medium-severity fixes, although since backports may be for low-severity fixes, it stands to reason that they would be more likely for more serious vulnerabilities.

High-severity issues, however, will prompt a new release of OpenSSL for all supported versions. As with medium-security issues, the existence of the vulnerability will be kept private until the release is ready for rollout. But the project vows that it will "attempt to keep the time these issues are private to a minimum; our aim would be no longer than a month where this is something under our control, and significantly quicker if there is a significant risk or we are aware the issue is being exploited."

Private practices

Naturally, the notion of keeping OpenSSL vulnerabilities private is one that may irk some software vendors and downstream projects. The "Background" section of the security policy makes the argument that disclosing vulnerabilities prior to the availability of a solution increases the likelihood of an exploit, but it also touts the benefits of peer review for patches. Finding the right balance, of course, is the tricky part.

In practice, the policy explains, OpenSSL's definition of "private" is quite specific. The project will announce upcoming releases on its openssl-announce mailing list, noting the approximate release date but not disclosing or describing the affected vulnerabilities in detail. The goal is to allow downstream users to put staff in place ready to deal with the new release once it is made, at which time the vulnerability will be disclosed.

Operating system vendors will receive somewhat more preferential treatment when the new release fixes a high-severity issue. To that end, the project uses the invitation-only distros mailing list hosted by Openwall, plus additional organizations selected by the OpenSSL project. The participating organizations receive prenotification of severe vulnerabilities and can provide testing and feedback with regard to patches.

Membership on this mailing list is a tightly managed affair, which has been the source of disagreements in the past, since inclusion gives a vendor advance warning of potentially useful vulnerability information. But the purpose of that prenotification is to improve the fixes so that vendors can release package updates ready when the vulnerability is disclosed, because so many OpenSSL users rely on their operating system's packages. It is not simply a "preferred client" program.

Such a distinction is not always clear, at least if history is any guide. In June, for example, VMware requested to be added to the Openwall linux-distros list (linux-distros is a subset of the distros list, which also includes FreeBSD and NetBSD). The company's request was denied when (among others) Greg Kroah-Hartman argued that although VMware uses many open-source software components—including the Linux kernel—it does not contribute back to the community. Being a participating, contributing member of the open-source community is a prerequisite for being eligible to receive prenotifications.

The OpenSSL policy incorporates wording in several places to distinguish between the feedback aspect of vulnerability prenotification and its potential for commercial exploitation. The Background section notes:

and, later:

In addition, the section of the policy describing the prenotification process reiterates that the intent is to improve the resulting fixes. As such, OpenSSL may decide that any particular organization (among those OpenSSL has selected in addition to the distros list) is not advancing this goal, and thus remove it unilaterally:

On the openssl-dev list, it was this clause that prompted the only question to be asked about the new policy so far. Loganaden Velvindron requested additional clarification of the language describing how the project decides if a vendor is providing value, and asked if there was a rating system that the vendors themselves could refer to.

So far, Velvindron's question has received no response, which may suggest that the project and the members of the OpenSSL community, in general, just "know" the difference between a vendor that is providing value to the security handling process and one that is not. Certainly there are many portions of the newly published policy that draw on OpenSSL's long experience with handling vulnerabilities and releasing security updates. An increasing in funding may provide more developer attention, and it may result in more formal processes—but, for the most part, these changes are just further refinements of the work that OpenSSL has learned to do over many years of development.