about/secpolicy.wml

   1
   2 #use wml::openssl area=about page=secpol
   3
   4 <title>About, Security Policy</title>
   5 <h1><center>OpenSSL Security Policy</center></h1>
   6 <h2><center>Last modified 7th September 2014</center></h2>
   7 <p>
   8 <br>
   9 </p>
  10
  11
  12 <h1>Introduction</h1>
  13
  14 <p>
  15 Recent flaws have captured the attention of the media and highlighted
  16 how much of the internet infrastructure is based on OpenSSL.  We've
  17 never published our policy on how we internally handle security issues;
  18 that process being based on experience and has evolved
  19 over the years.
  20 </p>
  21
  22 <h1>Reporting security issues</h1>
  23
  24 <p>
  25 We have an email address which can be used to notify us of possible
  26 security vulnerabilities.  A subset of OpenSSL team members receive
  27 this mail, and messages can be sent using PGP encryption.  Full
  28 details are at <a href="../news/vulnerabilities.html">https://www.openssl.org/news/vulnerabilities.html</a>
  29 </p>
  30
  31 <p>
  32 When we are notified about an issue we engage resources within the
  33 OpenSSL team to investigate and prioritise it.  We may also utilise
  34 resources from the employers of our team members, as well as others
  35 we have worked with before.
  36 </p>
  37
  38 <h1>Background</h1>
  39
  40 <p>
  41 Everyone would like to get advance notice of security issues in OpenSSL.
  42 This is a complex topic and we need to set out some background
  43 with our findings:
  44 </p>
  45 <ul>
  46 <li><p>The more people you tell in advance the higher the likelihood that a
  47   leak will occur.  We have seen this happen before, both with OpenSSL
  48   and other projects.</p>
  49
  50 <li><p>A huge number of products from an equally large number of
  51   organisations use OpenSSL. It's not just secure websites, you're
  52   just as likely to find OpenSSL inside your smart TV, car, or fridge.</p>
  53
  54 <li><p>We strongly believe that the right to advance patches/info
  55   should not be based in any way on paid membership to some forum. You
  56   can not pay us to get security patches in advance.</p>
  57
  58 <li><p>We can benefit from peer review of the patches and advisory. Keeping
  59   security issues private means they can't get the level of testing or
  60   scrutiny that they otherwise would.</p>
  61
  62 <li><p>It is not acceptable for organisations to use advance notice in marketing
  63   as a competitive advantage.  For example "if you had bought our
  64   product/used our service you would have been protected a week ago".</p>
  65
  66 <li><p>There are actually not a large number of serious vulnerabilities in
  67   OpenSSL which make it worth spending significant time keeping our
  68   own list of vendors we trust, or signing framework agreements, or
  69   dealing with changes, and policing the policy.  This is a
  70   significant amount of effort per issue that is better spent on other
  71   things.</p>
  72
  73 <li><p>We have previously used third parties to handle notification for us
  74   including CPNI, oCERT, or CERT/CC, but none were suitable.</p>
  75
  76 <li><p>It's in the best interests of the Internet as a whole to get fixes
  77   for OpenSSL security issues out quickly. OpenSSL embargoes should be
  78   measured in days and weeks, not months or years.</p>
  79
  80 <li><p>Many sites affected by OpenSSL issues will be running a version of
  81   OpenSSL they got from some vendor (and likely bundled with an
  82   operating system).  The most effective way for these sites to get
  83   protected is to get an updated version from that vendor.  Sites who
  84   use their own OpenSSL compilations should be able to handle a quick
  85   patch and recompile once the issue is public.</p>
  86 </ul>
  87
  88 <h1>Internal handling of security issues</h1>
  89
  90 <p>This leads us to our policy for security issues notified to us or
  91 found by our team which are not yet public.</p>
  92
  93 <p>"private" means kept within the OpenSSL development team.</p>
  94
  95 <p>We will determine the risk of each issue being addressed.  We will
  96 take into account our experience dealing with past issues, versions
  97 affected, common defaults, and use cases.  We divide the issues into
  98 the following categories:</p>
  99
 100 <ul>
 101
 102 <li><p>low severity issues.  This includes issues such as those that only
 103   affect the openssl command line utility, unlikely configurations, or
 104   hard to exploit timing (side channel) attacks.  These will in
 105   general be fixed immediately in latest development versions, and may
 106   be backported to older versions that are still getting updates.  We
 107   will update the vulnerabilities page and note the issue CVE in the
 108   changelog and commit message, but they may not trigger new releases.</p>
 109
 110 <li><p>moderate severity issues.  This includes issues like crashes in
 111   client applications, flaws in protocols that are less commonly used
 112   (such as DTLS), and local flaws.  These will in general be kept
 113   private until the next release, and that release will be scheduled
 114   so that it can roll up several such flaws at one time.</p>
 115
 116 <li><p>high severity issues.  This includes issues affecting common
 117   configurations which are also likely to be exploitable.  Examples
 118   include a server DoS, a significant leak of server memory, and
 119   remote code execution.  These issues will be kept private and will
 120   trigger a new release of all supported versions.  We will attempt to
 121   keep the time these issues are private to a minimum; our aim would
 122   be no longer than a month where this is something under our control,
 123   and significantly quicker if there is a significant risk or we are
 124   aware the issue is being exploited.</p>
 125 </ul>
 126
 127 <p>During the investigation of issues we may work with individuals and
 128 organisations who are not on the development team.  We do this because
 129 past experience has shown that they can add value to our understanding
 130 of the issue and the ability to test patches.  In cases where
 131 protocols are affected this is the best way to mitigate the risk that
 132 a poorly reviewed update causes signficiant breakage, or to detect if
 133 issues are being exploited in the wild.  We have a strict policy on
 134 what these organisations and individuals can do with the information
 135 and will review the need on a case by case basis.</p>
 136
 137 <h1>Prenotification policy</h1>
 138
 139 <p>Where we are planning an update that fixes security issues we will
 140 notify the openssl-announce list and update the home page to give our
 141 scheduled update release date and time and the severity of issues
 142 being fixed by the update.  No futher information about the issues
 143 will be given.  This is to aid organisations that need to ensure they
 144 have staff available to handle triaging our announcement and what it
 145 means to their organisation.</p>
 146
 147 <p>For updates that include high severity issues we will also prenotify
 148 with more details and patches.  Our policy is to let the organisations
 149 that have a general purpose OS that uses OpenSSL have a few days
 150 notice in order to prepare packages for their users and feedback test
 151 results.</p>
 152
 153 <p>We use the mailing list described at
 154 <a href="http://oss-security.openwall.org/wiki/mailing-lists/distros">http://oss-security.openwall.org/wiki/mailing-lists/distros</a> for this.
 155 We may also include other organisations that would otherwise qualify
 156 for list membership.  We may withdraw notifying individual
 157 organisations from future prenotifications if they leak issues before
 158 they are public or over time do not add value (value can be added by
 159 providing feedback, corrections, test results, etc.)</p>
 160
 161 <p>Finally, note that not all security issues are notified to us
 162 directly; some come from third parties such as companies that pay for
 163 vulnerabilities, some come from country CERTs.  These intermediaries,
 164 or the researchers themselves, may follow a different style of
 165 notification. This is within their rights and outside of the control
 166 of the OpenSSL team.</p>
 167