PEP 466: Network security enhancement exception
This commit is contained in:
Nick Coghlan
parent
b866a0f408
commit
668b05ec6c
|
|
@ -0,0 +1,283 @@
|
||||||
|
PEP: 466
|
||||||
|
Title: Network Security Enhancement Exception for All Branches
|
||||||
|
Version: $Revision$
|
||||||
|
Last-Modified: $Date$
|
||||||
|
Author: Nick Coghlan <ncoghlan@gmail.com>,
|
||||||
|
Status: Draft
|
||||||
|
Type: Informational
|
||||||
|
Content-Type: text/x-rst
|
||||||
|
Created: 23-Mar-2014
|
||||||
|
Post-History: 23-Mar-2014
|
||||||
|
|
||||||
|
|
||||||
|
Abstract
|
||||||
|
========
|
||||||
|
|
||||||
|
Most CPython tracker issues are classified as errors in behaviour or
|
||||||
|
proposed enhancements. Most patches to fix behavioural errors are
|
||||||
|
applied to all active maintenance branches. Enhancement patches are
|
||||||
|
restricted to the default branch that becomes the next Python version.
|
||||||
|
|
||||||
|
This PEP relaxes the latter restriction allowing enhancements to be applied
|
||||||
|
to maintenance branches for standard library components that have
|
||||||
|
implications for the overall security of the internet. In particular, the
|
||||||
|
exception will apply to:
|
||||||
|
|
||||||
|
* the ``ssl`` module
|
||||||
|
* the ``hashlib`` module
|
||||||
|
* the ``hmac`` module
|
||||||
|
* the ``sha`` module (Python 2 only)
|
||||||
|
* the components of other networking modules that make use of these modules
|
||||||
|
* the components of the ``random`` and ``os`` modules that are relevant to
|
||||||
|
cryptographic applications
|
||||||
|
* the version of OpenSSL bundled with the binary installers
|
||||||
|
|
||||||
|
Changes to these modules will still need to undergo normal backwards
|
||||||
|
compatibility assessments, but new features will be permitted where
|
||||||
|
appropriate, making it easier to implement secure networked software in
|
||||||
|
Python, even for software that needs to remain compatible with older feature
|
||||||
|
releases of Python.
|
||||||
|
|
||||||
|
|
||||||
|
Exemption Policy
|
||||||
|
================
|
||||||
|
|
||||||
|
Under this policy, the following network security related modules are
|
||||||
|
granted a blanket exemption to the restriction against adding new features
|
||||||
|
in maintenance releases:
|
||||||
|
|
||||||
|
* the ``ssl`` module
|
||||||
|
* the ``hashlib`` module
|
||||||
|
* the ``hmac`` module
|
||||||
|
* the ``sha`` module (Python 2 only)
|
||||||
|
|
||||||
|
This exemption applies to *all* proposals to backport backwards compatible
|
||||||
|
features in these modules to active maintenance branches. This choice is
|
||||||
|
made deliberately to ensure that the "feature or fix?" argument isn't simply
|
||||||
|
replaced by a "security related or not?" argument. These particular modules
|
||||||
|
are inherently security related, and all enhancements to them improve
|
||||||
|
Python's capabilities as a platform for development of secure networked
|
||||||
|
software.
|
||||||
|
|
||||||
|
As part of this policy, permission is also granted to upgrade to newer
|
||||||
|
feature releases of OpenSSL when preparing the binary installers
|
||||||
|
for new maintenance releases of CPython.
|
||||||
|
|
||||||
|
In addition to the above blanket exemption, a conditional exemption is
|
||||||
|
granted for these modules that may include some network security related
|
||||||
|
features:
|
||||||
|
|
||||||
|
* the ``os`` module (primarily ``os.urandom``)
|
||||||
|
* the ``random`` module
|
||||||
|
* networking related modules that depend on one or more of the network
|
||||||
|
security related modules listed above
|
||||||
|
|
||||||
|
This more limited exemption for these modules requires that the *specific*
|
||||||
|
enhancement being proposed for backporting needs to be justified as being
|
||||||
|
network security related. If the enhancement under discussion is designed
|
||||||
|
to take advantage of a new feature in one of the network security related
|
||||||
|
modules, then that will be taken as implying that the enhancement is
|
||||||
|
security related.
|
||||||
|
|
||||||
|
|
||||||
|
Backwards Compatibility Considerations
|
||||||
|
======================================
|
||||||
|
|
||||||
|
This PEP does *not* grant any general exemptions to the usual backwards
|
||||||
|
compatibility policy for maintenance releases. Instead, it is designed
|
||||||
|
to make it easier to provide more "secure by default" behaviour in future
|
||||||
|
feature releases, while still limiting the risk of breaking currently
|
||||||
|
working software when upgrading to a new maintenance release.
|
||||||
|
|
||||||
|
In *all* cases where this policy is applied to backport enhancements to
|
||||||
|
maintenance releases, it MUST be possible to write cross-version compatible
|
||||||
|
code that operates by "feature detection" (for example, checking for
|
||||||
|
particular attributes in the module), without needing to explicitly check
|
||||||
|
the Python version.
|
||||||
|
|
||||||
|
It is then up to library and framework code to provide an appropriate error
|
||||||
|
message or fallback behaviour if a desired feature is found to be missing.
|
||||||
|
|
||||||
|
Affected APIs SHOULD be designed to allow library and application code to
|
||||||
|
perform the following actions after detecting the presence of a relevant
|
||||||
|
network security related feature:
|
||||||
|
|
||||||
|
* explicitly opt in to more secure settings (to allow the use of enhanced
|
||||||
|
security features in older versions of Python)
|
||||||
|
* explicitly opt in to less secure settings (to allow the use of newer Python
|
||||||
|
versions in lower security environments)
|
||||||
|
* determine the default setting for the feature (this MAY require explicit
|
||||||
|
Python version checks to determine the Python feature release, but MUST
|
||||||
|
NOT depend on the specific maintenance release)
|
||||||
|
|
||||||
|
|
||||||
|
Documentation Requirements
|
||||||
|
==========================
|
||||||
|
|
||||||
|
All modules that take advantage of this policy to backport network
|
||||||
|
security related enhancements to earlier Python versions MUST include
|
||||||
|
a "Security Considerations" section in their documentation.
|
||||||
|
|
||||||
|
In addition to any other module specific contents, this section MUST
|
||||||
|
enumerate key security enhancements and fixes (with CVE identifiers where
|
||||||
|
applicable), and the
|
||||||
|
|
||||||
|
|
||||||
|
Evolution of this Policy
|
||||||
|
========================
|
||||||
|
|
||||||
|
The key requirement for a module to be considered for inclusion in this
|
||||||
|
policy (whether under a blanket or conditional exemption) is that it must
|
||||||
|
have security implications *beyond* the specific application that is written
|
||||||
|
in Python and the system that application is running on. Thus the focus on
|
||||||
|
network security protocols and related cryptographic infrastructure - Python
|
||||||
|
is a popular choice for the development of web services and clients, and
|
||||||
|
thus the capabilities of widely used Python versions have implications for
|
||||||
|
the security design of other services that may be using newer versions of
|
||||||
|
Python or other development languages.
|
||||||
|
|
||||||
|
The intent behind this requirement is to minimise any impact that the
|
||||||
|
introduction of this policy may have on the stability and compatibility of
|
||||||
|
maintenance releases. It would be thoroughly counterproductive if end
|
||||||
|
users became as cautious about updating to new Python maintenance releases
|
||||||
|
as they are about updating to new feature releases.
|
||||||
|
|
||||||
|
|
||||||
|
Motivation and Rationale
|
||||||
|
========================
|
||||||
|
|
||||||
|
This PEP can be seen as a more targeted version of the "faster standard
|
||||||
|
library release cycle" proposals discussed in PEP 407 and PEP 413,
|
||||||
|
focusing specifically on those areas which have implications beyond the
|
||||||
|
Python community.
|
||||||
|
|
||||||
|
The creation of this PEP was prompted primarily by the aging SSL support in
|
||||||
|
the Python 2 series. As of March 2014, the Python 2.7 SSL module is
|
||||||
|
approaching four years of age, and the SSL support in the still popular
|
||||||
|
Python 2.6 release had its feature set locked six years ago.
|
||||||
|
|
||||||
|
These are simply too old to provide a foundation that can be recommended
|
||||||
|
in good conscience for secure networking software that operates over the
|
||||||
|
public internet, especially in an era where it is becoming quite clearly
|
||||||
|
evident that advanced persistent security threats are even more widespread
|
||||||
|
and more indiscriminate in their targeting than had previously been
|
||||||
|
understood.
|
||||||
|
|
||||||
|
While the use of the system OpenSSL installation addresses many of these
|
||||||
|
concerns on Linux platforms, it doesn't address all of them, and in the
|
||||||
|
case of the binary installers for Windows and Mac OS X that are published
|
||||||
|
on python.org, the version of OpenSSL used is entirely within the control
|
||||||
|
of the Python core development team.
|
||||||
|
|
||||||
|
With increased popularity comes increased responsibility, and this policy
|
||||||
|
is about recognising the fact that Python's popularity and adoption has now
|
||||||
|
reached a level where some of our design and policy decisions have
|
||||||
|
significant implications beyond the Python development community.
|
||||||
|
|
||||||
|
As one example, the Python 2 ``ssl`` module does not support the Server
|
||||||
|
Name Identification standard. While it is possible to obtain SNI support
|
||||||
|
by using the third party ``requests`` client library, actually doing so
|
||||||
|
currently requires using not only ``requests`` and its embedded dependencies,
|
||||||
|
but also half a dozen or more additional libraries. The lack of support
|
||||||
|
in the Python 2 series thus serves as an impediment to making effective
|
||||||
|
use of SNI on servers, as Python 2 clients will frequently fail to handle
|
||||||
|
it correctly.
|
||||||
|
|
||||||
|
Another more critical example is the lack of SSL hostname matching in the
|
||||||
|
Python 2 standard library - it is currently necessary to rely on a third
|
||||||
|
party library, such as ``requests`` or ``backports.ssl_match_hostname`` to
|
||||||
|
obtain that functionality in Python 2.
|
||||||
|
|
||||||
|
The Python 2 series also remains more vulnerable to remote timing attacks
|
||||||
|
on security sensitive comparisons than the Python 3 series, as it lacks a
|
||||||
|
standard library equivalent to the timing attack resistant
|
||||||
|
``hmac.compare_digest()`` function. While appropriate secure comparison
|
||||||
|
functions can be implemented in third party extensions, may users don't
|
||||||
|
even consider the problem and use ordinary equality comparisons instead
|
||||||
|
- while a standard library solution doesn't automatically fix that problem,
|
||||||
|
it *does* make the barrier to resolution much lower once the problem is
|
||||||
|
pointed out.
|
||||||
|
|
||||||
|
My position on the ongoing transition from Python 2 to Python 3 has long
|
||||||
|
been that Python 2 remains a supported platform for the core development
|
||||||
|
team, and that commercial support will remain available well after upstream
|
||||||
|
maintenance ends. However, in the absence of this network security
|
||||||
|
enhancement policy, that position is difficult to justify when it comes to
|
||||||
|
software that operates over the public internet. Just as many developers
|
||||||
|
consider it too difficult to develop truly secure modern networked software
|
||||||
|
in C/C++ (largely due to the challenges associated with manual
|
||||||
|
memory management), I consider it too difficult to develop truly secure
|
||||||
|
modern networked software using the Python 2 series without introducing this
|
||||||
|
network security enhancement policy, as doing so would mean reimplementing
|
||||||
|
substantial portions of the standard library as third party modules to gain
|
||||||
|
access to the newer underlying network security protocols and mechanisms,
|
||||||
|
and then injecting those into the module namespace to override their
|
||||||
|
standard library counterparts.
|
||||||
|
|
||||||
|
Requiring that latent defects in an application's Unicode correctness be
|
||||||
|
addressed in order to migrate to Python 3 is not a reasonable alternative
|
||||||
|
recommendation, especially given the likely existence of legacy code that
|
||||||
|
lacks the kind of automated regression test suite needed to help support
|
||||||
|
a migration from Python 2 to Python 3. The key point of this PEP is that
|
||||||
|
those situations affect more people than just the developers and users of
|
||||||
|
the affected application: their existence becomes something that developers
|
||||||
|
of secure networked services need to take into account as part of their
|
||||||
|
security design. By making it more feasible to enhance the security of the
|
||||||
|
Python 2 series, we can help contribute to the evolution of a more secure
|
||||||
|
internet for all concerned.
|
||||||
|
|
||||||
|
For the Python 2 series, this proposal will most obviously impact the
|
||||||
|
remaining maintenance releases of Python 2.7. However, commercial
|
||||||
|
redistributors that continue to offer full support for Python 2.6, and will
|
||||||
|
also do so for Python 2.7 after upstream maintenance ends, may choose
|
||||||
|
to take this policy into account when deciding what changes to backport to
|
||||||
|
their own maintenance updates. Providing commercial redistributors such
|
||||||
|
as ActiveState, Attachmate, Canonical, Continuum Analytics, Enthought, and
|
||||||
|
Red Hat that option is one of the benefits offered by requiring feature
|
||||||
|
detection based forward compatibility for the modules covered by this policy.
|
||||||
|
|
||||||
|
|
||||||
|
Open Questions
|
||||||
|
==============
|
||||||
|
|
||||||
|
* What are the risks associated with allowing OpenSSL to be updated to
|
||||||
|
new feature versions in the Windows and Mac OS X binary installers for
|
||||||
|
maintenance releases?
|
||||||
|
|
||||||
|
* Are there any other security relevant modules that should be covered
|
||||||
|
by either a blanket or conditional exemption?
|
||||||
|
|
||||||
|
* Should we enumerate a specific list of "other networking modules" rather
|
||||||
|
than leaving it implicit?
|
||||||
|
|
||||||
|
|
||||||
|
Acknowledgement
|
||||||
|
===============
|
||||||
|
|
||||||
|
Thanks to Christian Heimes for his recent efforts on greatly improving
|
||||||
|
Python's SSL support in the Python 3 series, and a variety of members of
|
||||||
|
the Python community for helping me to better understand the implications
|
||||||
|
of the default settings we provide in our SSL modules, and the impact that
|
||||||
|
tolerating the use of SSL infrastructure that was defined in 2010
|
||||||
|
(Python 2.7) or even 2008 (Python 2.6) potentially has for the security
|
||||||
|
of the web as a whole.
|
||||||
|
|
||||||
|
Christian and Donald Stufft also provided valuable feedback on a preliminary
|
||||||
|
draft of this proposal.
|
||||||
|
|
||||||
|
|
||||||
|
Copyright
|
||||||
|
=========
|
||||||
|
|
||||||
|
This document has been placed in the public domain.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
..
|
||||||
|
Local Variables:
|
||||||
|
mode: indented-text
|
||||||
|
indent-tabs-mode: nil
|
||||||
|
sentence-end-double-space: t
|
||||||
|
fill-column: 70
|
||||||
|
coding: utf-8
|
||||||
|
End:
|
||||||
Loading…
Reference in New Issue