diff --git a/pep-0493.txt b/pep-0493.txt new file mode 100644 index 000000000..ad0d66739 --- /dev/null +++ b/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 , Robert Kuska +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