Cryptography and SSL/TLS Toolkit

Security Policy

Last modified 28th September 2015


Recent flaws have captured the attention of the media and highlighted how much of the internet infrastructure is based on OpenSSL. 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.

Reporting security issues

We have an email address which can be used to notify us of possible security vulnerabilities. A subset of OpenSSL team members receive this mail, and messages can be sent using PGP encryption. Full details are at

When we are notified about an issue we engage resources within the OpenSSL team to investigate and prioritise it. We may also utilise resources from the employers of our team members, as well as others we have worked with before.


Everyone would like to get advance notice of security issues in OpenSSL. This is a complex topic and we need to set out some background with our findings:

  • The more people you tell in advance the higher the likelihood that a leak will occur. We have seen this happen before, both with OpenSSL and other projects.
  • A huge number of products from an equally large number of organisations use OpenSSL. It's not just secure websites, you're just as likely to find OpenSSL inside your smart TV, car, or fridge.
  • We strongly believe that the right to advance patches/info should not be based in any way on paid membership to some forum. You can not pay us to get security patches in advance.
  • We can benefit from peer review of the patches and advisory. Keeping security issues private means they can't get the level of testing or scrutiny that they otherwise would.
  • It is not acceptable for organisations to use advance notice in marketing as a competitive advantage. For example "if you had bought our product/used our service you would have been protected a week ago".
  • There are actually not a large number of serious vulnerabilities in OpenSSL which make it worth spending significant time keeping our own list of vendors we trust, or signing framework agreements, or dealing with changes, and policing the policy. This is a significant amount of effort per issue that is better spent on other things.
  • We have previously used third parties to handle notification for us including CPNI, oCERT, or CERT/CC, but none were suitable.
  • It's in the best interests of the Internet as a whole to get fixes for OpenSSL security issues out quickly. OpenSSL embargoes should be measured in days and weeks, not months or years.
  • Many sites affected by OpenSSL issues will be running a version of OpenSSL they got from some vendor (and likely bundled with an operating system). The most effective way for these sites to get protected is to get an updated version from that vendor. Sites who use their own OpenSSL compilations should be able to handle a quick patch and recompile once the issue is public.

Internal handling of security issues

This leads us to our policy for security issues notified to us or found by our team which are not yet public.

"private" means kept within the OpenSSL development team.

We will determine the risk of each issue being addressed. We will take into account our experience dealing with past issues, versions affected, common defaults, and use cases. We divide the issues into the following categories:

  • CRITICAL Severity. This affects common configurations and which are also likely to be exploitable. Examples include significant disclosure of the contents of server memory (potentially revealing user details), vulnerabilities which can be easily exploited remotely to compromise server private keys (excluding local, theoretical or difficult to exploit side channel attacks) or where remote code execution is considered likely in common situations. These issues will be kept private and will trigger a new release of all supported versions. We will attempt to address these as soon as possible.
  • HIGH Severity. This includes issues that are of a lower risk than critical, perhaps due to affecting less common configurations, or which are less likely to be exploitable. These issues will be kept private and will trigger a new release of all supported versions. 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
  • MODERATE Severity. This includes issues like crashes in client applications, flaws in protocols that are less commonly used (such as DTLS), and local flaws. These will in general be kept private until the next release, and that release will be scheduled so that it can roll up several such flaws at one time.
  • LOW Severity. This includes issues such as those that only affect the openssl command line utility, unlikely configurations, or hard to exploit timing (side channel) attacks. These will in general be fixed immediately in latest development versions, and may be backported to older versions that are still getting updates. We will update the vulnerabilities page and note the issue CVE in the changelog and commit message, but they may not trigger new releases.

During the investigation of issues we may work with individuals and organisations who are not on the development team. We do this because past experience has shown that they can add value to our understanding of the issue and the ability to test patches. In cases where protocols are affected this is the best way to mitigate the risk that a poorly reviewed update causes significant breakage, or to detect if issues are being exploited in the wild. We have a strict policy on what these organisations and individuals can do with the information and will review the need on a case by case basis.

Prenotification policy

Where we are planning an update that fixes security issues we will notify the openssl-announce list and update the home page to give our scheduled update release date and time and the severity of issues being fixed by the update. No further information about the issues will be given. This is to aid organisations that need to ensure they have staff available to handle triaging our announcement and what it means to their organisation.

For updates that include critical or high severity issues we will also prenotify with more details and patches. Our policy is to let the organisations 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.

We use the mailing list described at for this. We may also include other organisations that would otherwise qualify for list membership. We may withdraw notifying individual organisations from future prenotifications if they leak issues before they are public or over time do not add value (value can be added by providing feedback, corrections, test results, etc.)

Finally, note that not all security issues are notified to us directly; some come from third parties such as companies that pay for vulnerabilities, some come from country CERTs. These intermediaries, or the researchers themselves, may follow a different style of notification. This is within their rights and outside of the control of the OpenSSL team.