<!DOCTYPE html>
<html lang="en">
<!--#include virtual="/inc/head.shtml" -->
<body>
<!--#include virtual="/inc/banner.shtml" -->
<div id="main">
<div id="content">
<div class="blog-index">
<article>
<header>
<h2>Security Policy</h2>
<h5>
Last modified 15th January 2018
</h5>
</header>
<div class="entry-content">
<h2>Reporting security issues</h2>
<p>
If you wish to report a possible security issue in OpenSSL
please <a href="/news/vulnerabilities.html">notify us</a>.
</p>
<h2>Issue triage</h2>
<p>
Notifications are received by a group of OpenSSL Management Committee
members. We engage resources within
OpenSSL to start the investigation and prioritisation. We may work in private
with individuals who are not on the OpenSSL Management Committee as
well as other organisations and
our <a href="/community/thanks.html">employers</a> where we believe
this can help with the issue investigation, resolution, or
testing.</p>
</p>
<h2>Issue severity</h2>
<p>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:</p>
<ul>
<li><em>CRITICAL Severity.</em>
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.</li>
<li>
<em>HIGH Severity.</em>
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</li>
<li>
<em>MODERATE Severity.</em>
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.</li>
<li>
<em>LOW Severity.</em>
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.</li>
</ul>
<h2>Prenotification policy</h2>
<ul><li>Where we are planning an update that fixes security issues
we will notify the <a href="https://mta.openssl.org/mailman/listinfo/openssl-announce">openssl-announce list</a> and update the OpenSSL
website 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.</li>
<li>Where we are planning an update that include CRITICAL or HIGH severity issues we will
also prenotify certain organisations with more details and
patches. <ul>
<li>The organisations we prenotify include those that produce a
a general purpose OS
that uses OpenSSL as included on
<a
href="http://oss-security.openwall.org/wiki/mailing-lists/distros">this
list of Operating System distribution security contacts</a>.</li>
<li>We may also include other organisations that are not listed but
would otherwise qualify for list membership. </li>
<li>We may
withdraw notifying certain organisations from future
prenotifications if they leak issues before they are public
or over time do not add value. </li></ul></li></ul>
<p>Note: researchers or intermediaries who
notify us of issues may have their own prenotification policy in addition
to ours.</p>
<h2>Principles</h2>
<p>The policy above is guided by our security principles:</p>
<ul>
<li>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.</li>
<li>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.</li>
<li>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.</li>
</ul>
</div>
<footer>
You are here: <a href="/">Home</a>
: <a href=".">Policies</a>
: <a href="">Security Policy</a>
<br/><a href="/sitemap.txt">Sitemap</a>
</footer>
</article>
</div>
<!--#include virtual="sidebar.shtml" -->
</div>
</div>
<!--#include virtual="/inc/footer.shtml" -->
</body>
</html>