If I could summarize this discussion (please correct me if I am wrong):
1. Status Quo
All existing versions of Python are unsecure by default
because by not doing SSL hostname verification,
libraries which wrap sockets with SSLContext
allow SSL MITM (man-in-the-middle) with no warning.
Christian Heimes has introduced ss.create_default_context for 3.4
Donald Stuft is proposing that hostname verification should be
the default behavior in future versions of Python;
such as Python 3.4,
ideally as soon as possible.
python-dev has been resistant to preventing SSL MITM by default
because humans, pypi:keyring, and pypi:certifi
2. Generalizations about end-users:
* corporate users aren't susceptible to MITM because perimeter
* fallacious on all accounts
* mismatched metaphors abound
* nobody knows how to add self-signed CA certs to their chains
* Agreed.
* most people haven't / aren't going to read the docs:
A **warning::** would probably be appropriate
(and a big red warning box has been added to the 3.3 docs)
It could also say "PYTHON DOES NOT VALIDATE SSL CERTIFICATES BY DEFAULT"
* most people don't realize / have modification rights / have the
ability to submit patches upstream; either to
* set CERT_REQUIRED for every connection
* set (a forthcoming) CERT_NOVALIDATE
* people who complain about breaking security defaults
which allow MITM are most relevant
* "it doesn't work on my SOHO router"
* people would need to understand how Python
(and many other languages' SSL implementations)
is less secure than current browsers
* people don't read "What's New"; distributions test and upgrade their
interpreter for them
* some people are aware that third-party libraries requests and urllib3
do SSL hostname validation by default, now, with Python 2
3. Compatibility
There could be a PYTHONSSLNOVALIDATE environment variable:
* +1 : This would allow workarounds for applications which cannot be
updated
* -1 : This is not preferable because PYTHONHASHSEED
4. Chain management
* It should be possible to update the cert chain
* It could be easier to specify a different cert chain (?)
* Python 3.4 now supports using the Windows cert chain
* Pip does not yet support using the Windows cert chain
* pypi:certifi adds the Mozilla Firefox keychain for Python 2 and 3
(like requests and pip)
5. Deprecation
* Should deprecate slowly (2017) because people would complain about
having been secured against MITM (in their upgrade to Python 3.4)
* Should not deprecate slowly because the status quo
(insecure by default) is risky
* Should add pending deprecation now (see CERT_NOVALIDATE NOP below)
6. Testing Responses
* It's probably good to start testing downstream patches
to Python 3.4 packages
* The error message may be primed
My two cents:
* CERT_NOVALIDATE could/should be present now (if even as a no-op)
* 2to3 could/should add CERT_NOVALIDATE
Please feel free to add any, all, or none of this to the forthcoming PEP.
Thank you for addressing this issue.
(This is buried here because the mailman archive gzip hasn't yet updated with
the latest Message-Id to specify for In-Reply-To)