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:
http://docs.python.org/3/library/ssl.html#verifying-certificates
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)
--
Wes Turner
On Wed, Jan 22, 2014 at 12:46 PM, Brian Curtin <br...@python.org> wrote:
> On Wed, Jan 22, 2014 at 12:10 PM, John Yeuk Hon Wong
> <gokoproj...@gmail.com> wrote:
> > On 1/22/14 8:16 AM, Nick Coghlan wrote:
> >>
> >> Which is exactly the way most non-web-specialists working inside the
> >> comfort of corporate and academic firewalls will react to a change that
> >> breaks their access to internal applications, where self-signed certs
> and
> >> improperly configured internal CAs are endemic (of course, that's
> assuming
> >> they're using HTTPS at all, which I admit is an optimistic assumption).
> >
> > The number of people who are using 3.4+ in these environments is probably
> > very very low to be honest. I don't have a number to prove, but in that
> > environment people are more likely to still be using 2.6+. I think a
> > deprecation in 2.7+ would be nice, but forward we should just enable it
> by
> > default.
> >
> > When requests changed property calls (e.g. requests.json) to callable
> > instead of an attribute(from requests.json to requests.json()), I was
> > shocked. I had to figure out by Googling it. I found out from github
> > issue....
> >
> > I think a hard fail is somehow necessary.
> >
> > Also, a lot of people overlook at deprecation warnings. They either don't
> > care or don't see it. I see a lot of deprecation warnings in the older
> > applications I write, but I can careless until it breaks. So as we moving
> > forward, we can break it. For those stuck behind, deprecation is the
> right
> > approach.
>
> They're disabled by default, so a lot of people simply don't know they
> exist because they also don't read the documentation.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/wes.turner%40gmail.com
>
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
