Security Policy

Reporting security issues

If you wish to report a possible security issue in OpenSSL please notify us by sending an e-mail to openssl-security@openssl.org.

If you have multiple issues to report, please always send a separate e-mail for each issue.

Issue triage

Notifications are received by the OpenSSL Security Response Team (SRT) designated by the OpenSSL Foundation and the OpenSSL Corporation directors. The SRT contains resources from within the OpenSSL Foundation and the OpenSSL Corporation and also members from the Committers community who decided to participate in the SRT.

We may work in private with individuals who are not part of the SRT as well as other organisations where we believe this can help with the issue investigation, resolution, or testing.

Threat Model

Certain threats are currently considered outside of the scope of the OpenSSL threat model. Accordingly, we do not consider OpenSSL secure against the following classes of attacks:

• same physical system side channel
• CPU/hardware flaws
• physical fault injection
• physical observation side channels (e.g. power consumption, EM emissions, etc)
• those which just cause a denial of service of the OpenSSL command line utility
• API misuse by an application where such API is not supposed to be directly exposed to attacker-controlled data

Mitigations for security issues outside of our threat scope may still be addressed, however we do not class these as OpenSSL vulnerabilities and will therefore not issue CVEs for any mitigations to address these issues.

Prior to the threat model being included in this policy, CVEs were sometimes issued for these classes of attacks. The existence of a previous CVE does not override this policy going forward.

Issue severity

We will determine the risk of each issue, taking into account our experience dealing with past issues, versions affected, common defaults, and use cases. We use the following severity 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 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, affecting only protocol clients, 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 whose impact is only a denial of service, flaws in protocols that are less commonly used (such as CMP), 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, cause only a denial of service for less common protocols or on client side only, or require multiple unlikely conditions to be fulfilled for the attack to succeed. These will in general be handled in the similar way as the Moderate issues. However, as an exception, they might be developed and fixed in public before the next release, for example in case the flaw is rather theoretical and fixing it requires extensive design and development. In such case we will update the vulnerabilities page and note the issue CVE in the changelog and commit message, but we will not publish new releases immediately.

Prenotification policy

• Where we are planning an update that fixes security issues we will notify the openssl-announce list 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 usually done one week before the actual release.
• Where we are planning an update that includes Critical, High, or Moderate severity issues we will also prenotify certain organisations with more details and patches. We usually do that two weeks before the actual release.
  • The organisations we prenotify include those that produce a general purpose OS that uses OpenSSL as included on this list of Operating System distribution security contacts.
  • We also include other open source projects that are derived from OpenSSL which have a significant user base and a reciprocal arrangement.
  • We may also include other organisations that are not listed but would otherwise qualify for list membership.
  • We may also include organisations with which we have a commercial relationship.
  • We may withdraw notifying certain organisations from future prenotifications if they leak issues before they are public or over time do not add value.

Note: researchers or intermediaries who notify us of issues may have their own prenotification policy in addition to ours.

Principles

The policy above is guided by our security principles:

• 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.

This policy is primarily guidance and there might be exceptions to it if they are warranted by the circumstances. For example, if a fix for a seemingly regular issue, that was already published, is later determined to fix a security issue, some parts of the process for handling security issues might be skipped for that issue.

Security release update recommendations

Our security advisories describe the affected configurations or applications. We always recommend reviewing the advisories before updating the systems running the unfixed releases.

However in general it is a good idea to update the systems as soon as possible with the security update releases that contain Critical or High severity issue fixes.

As the Moderate and Low severity issues are either unlikely to be exploitable and/or the impact of the successful exploit is limited, we recommend scheduling the updates without undue haste.

CVSS score differences

The CVSS scoring system does not properly reflect the broad usage of the OpenSSL Library and does not fully account for likelihood of a configuration being affected. For that reason we do not use the CVSS scoring system to determine the severity and the CVSS score provided by independent parties might severely differ from the severity we have assigned.