OpenSSL has been having a rough go of it for some time thanks to Heartbleed and a handful of other critical vulnerabilities. Not only did those bugs put commerce and communication at risk, but they opened many people’s eyes as to how omnipresent the open source crypto implementation is.
In an effort to provide some transparency into how the OpenSSL Project handles, classifies and notifies users of security issues, the group yesterday for the first time made its security policy public.
“We’ve never published our policy on how we internally handle security issues; that process being based on experience and has evolved over the years,” the policy’s introduction reads.
The document grew out of the rubble of Heartbleed, said Rich Salz, a member of the OpenSSL development team, who added that because of OpenSSL’s ubiquity in commercial software and smaller independent projects, it was important to pull back the curtains.
“After Heartbleed, it was a wake-up call. The team at the time realized a number of things had to be addressed as we expanded from three or four people to the dozen we have now,” Salz said. “We needed to figure out a project governance, especially when you go from one or one-and-a-half people on a project to a dozen, you need some ground rules.”
While publication of the policy is a means to achieve greater transparency, the policy states that there are times when discretion is preferred. With high severity issues, such as server denial of service conditions, memory leaks or remote code execution bugs, the policy states that the details will be kept within the OpenSSL development team and triggers a new release.
“We 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,” the policy states.
Salz said defining the respective severity rankings took the longest to hammer out as the document was built. Vulnerabilities are ranked as high, moderate and low severity. Moderate severity issues are kept private as well until the next scheduled OpenSSL release, which will include a roll up over several patches. Low severity issues, meanwhile, would be patched in development versions and perhaps back-ported to versions still supported by the project. It’s unlikely a low severity issue, however, would trigger a new release.
“Any policy is good as long as it’s written down and you can point to it,” Salz said. “If you don’t document something, you leave yourself open to concerns and even accusations.”
The policy also points out that the number of critical OpenSSL vulnerabilities is relatively low and that the project sees no reason to have a list of trusted vendors or signing framework agreements. They have also shunned using third parties such as the CERT Coordination Center at Carnegie Mellon University, CPNI or oCERT to handle notifications.
“It’s in the best interests of the Internet as a whole to get fixes for OpenSSL security issues out quickly,” the policy states. “OpenSSL embargoes should be measured in days and weeks, not months or years.”
The OpenSSL Project, meanwhile, says it will continue to announce updates and security patches via the openssl-announce mailing list and provide scheduled update release dates and severity details on its home page.
“No further information about the issues will be given. This is to aid organizations that need to ensure they have staff available to handle triaging our announcement and what it means to their organization,” the policy states. “For updates that include high severity issues we will also pre-notify with more details and patches. Our policy is to let the organizations that have a general purpose OS that uses OpenSSL have a few days notice in order to prepare packages for their users and feedback test results.”
This article was updated at 1:30 p.m. ET with comments from the OpenSSL Project.
