Redistributor recommendations for PEP 476

pep-0493.txt

@@ -0,0 +1,158 @@
+PEP: 493
+Title: HTTPS verification recommendations for Python 2.7 redistributors
+Version: $Revision$
+Last-Modified: $Date$
+Author: Nick Coghlan <ncoghlan@gmail.com>, Robert Kuska <rkuska@redhat.com>
+Status: Draft
+Type: Informational
+Content-Type: text/x-rst
+Created: 10-May-2015
+
+Abstract
+========
+
+PEP 476 updated Python's default handling of HTTPS certificates to be
+appropriate for communication over the public internet. The Python 2.7 long
+term maintenance series was judged to be in scope for this change, with the
+new behaviour introduced in the Python 2.7.9 maintenance release.
+
+This PEP provides recommendations to downstream redistributors wishing to
+provide a smoother migration experience when helping their users to manage
+this change in Python's default behaviour.
+
+.. note::
+
+   Note that this PEP is not currently accepted, so it is a *proposed*
+   recommendation, rather than an active one.
+
+Rationale
+=========
+
+PEP 476 changed Python's default behaviour to better match the needs and
+expectations of developers operating over the public internet, a category
+which appears to include most new Python developers. It is the position of
+the authors of this PEP that this was a correct decision.
+
+However, it is also the case that this change *does* cause problems for
+infrastructure administrators operating private intranets that rely on
+self-signed certificates, or otherwise encounter problems with the new default
+certificate verification settings.
+
+The long term answer for such environments is to update their internal
+certificate management to at least match the standards set by the public
+internet, but in the meantime, it is desirable to offer these administrators
+a way to continue receiving maintenance updates to the Python 2.7 series,
+without having to gate that on upgrades to their certificate management
+infrastructure.
+
+PEP 476 did attempt to address this question, by covering how to revert the
+new settings process wide by monkeypatching the ``ssl`` module to restore the
+old behaviour. Unfortunately, the ``sitecustomize.py`` based technique proposed
+to allow system administrators to disable the feature by default in their
+Standard Operating Environment definition has been determined not to work in
+at least some cases. The specific case of interest to the authors of this PEP
+is the one where a commercial redistributor aims to provide their users with
+a smoother migration path than the standard one provided by consuming the
+upstream CPython 2.7 distribution directly [#].
+
+.. [#] https://bugzilla.redhat.com/show_bug.cgi?id=1173041
+
+Rather than allowing a plethora of mutually incompatibile migration techniques
+to bloom, this PEP proposes a recommended approach for redistributors to take
+when addressing this problem on behalf of their users that provides the
+following capabilities:
+
+* infrastructure administrators restoring the old behaviour as part of their
+  standard system configuration
+* redistributors restoring the old behaviour as part of their standard
+  platform configuration
+* infrastructure administators optionally and explicitly opting in to accepting
+  a change in default behaviour at a future point in time as determined by their
+  chosen redistributor
+
+It aims to do this without introducing any new attack vectors that allow
+the security configuration to be downgraded back to the older less secure
+defaults.
+
+This design is being proposed as a recommendation for redistributors, rather
+than as a new upstream feature, as it is needed primarily to support legacy
+environments migrating from older versions of Python 2.7 (The PEP authors
+aren't *opposed* to this capability existing as an upstream feature, we just
+don't need that ourselves - our aim is to avoid different redistributors
+doing different things, not to push the change upstream).
+
+Recommendation
+==============
+
+To smooth the migration path to verifying HTTPS certificates by default, it is
+recommended that redistributors:
+
+* patch the ``ssl`` module to read a global configuration file when the module
+  is imported
+* default to verifying certificates if this configuration file is not present
+* support the following three modes of operation in that configuration file:
+
+  * ensure HTTPS certificate verification is enabled
+  * ensure HTTPS certificate verification is disabled
+  * delegate the decision to the redistributor modifying upstream Python
+
+An example patch is available at [#].
+
+.. [#] https://bugs.python.org/issue23857
+
+Recommended file location
+-------------------------
+
+TBD separately for \*nix and Windows
+
+Recommended file format
+-----------------------
+
+ConfigParser ini-style format, other details TBD
+
+Security Considerations
+=======================
+
+The specific recommendations here are designed to work for privileged, security
+sensitive processes, being run in the following locked down configuration:
+
+* run from a locked down administrator controlled directory rather than a normal
+  user directory (preventing ``sys.path[0]`` based privilege escalation attacks)
+* run using the ``-E`` switch (preventing ``PYTHON*`` environment variable based
+  privilege escalation attacks)
+* run using the ``-s`` switch (preventing user site directory based privilege
+  escalation attacks)
+* run using the ``-S`` switch (preventing ``sitecustomize`` based privilege
+  escalation attacks)
+
+The intent is that the *only* reason HTTPS verification should be getting
+turned off globally is because:
+
+* an end user is running a redistributor supported version of CPython rather
+  than running upstream CPython directly
+* that redistributor has decided to provide a smoother migration path to
+  verifying HTTPS certificates by default than that being provided by the
+  upstream project
+* either the redistributor or the local infrastructure administrator has
+  determined that it is appropriate to override the default upstream behaviour
+  (at least for the time being)
+
+Using an administrator controlled configuration file rather than an environment
+variable not only provides compatibility with the ``-E`` switch, but also
+ensures that in any situation where an attacker gains sufficient access to allow
+them to modify the configuration file, they're likely already in a position to
+attack the system certificate store directly.
+
+Copyright
+=========
+
+This document has been placed into the public domain.
+
+
+..
+   Local Variables:
+   mode: indented-text
+   indent-tabs-mode: nil
+   sentence-end-double-space: t
+   fill-column: 70
+   coding: utf-8