[Python-Dev] PYTHONHTTPSVERIFY env var

[Donald Stufft]

> On May 11, 2015, at 6:47 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> On 11 May 2015 at 20:23, Donald Stufft <donald at stufft.io> wrote:
>> On May 11, 2015, at 6:15 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> We made the decision when PEP 476 was accepted that this change turned
>>> a silent security failure into a noisy one, rather than being a
>>> regression in its own right. PEP 493 isn't about disagreeing with that
>>> decision, it's about providing a smoother upgrade path in contexts
>>> where letting the security failure remain silent is deemed to be
>>> preferred in the near term.
>> 
>> I don't really agree that the decision to disable TLS is an environment one,
>> it's really a per application decision. This is why I was against having some
>> sort of global off switch for all of Python because just because one
>> application needs it turned off doesn't mean you want it turned off for another
>> Python application.
> 
> The scenario I'm interested in is the one where it *was* off globally
> (i.e. you were already running Python 2.7.8 or earlier) and you want
> to manage a global rollout of a new Python version that supports being
> configured to verify HTTPS certificates by default, while making the
> decision on whether or not to enable HTTPS certificate verification on
> a server-by-server basis, rather than having that decision be coupled
> directly to the rollout of the updated version of Python.
> 
> I agree that the desired end state is where Python 3 is, and where
> upstream Python 2.7.9+ is, this is solely about how to facilitate
> folks getting from point A to point B without an intervening window of
> "I broke the world and now my boss is yelling at me about it" :)
> 

Oh, another issue that I forgot to mention--

A fair number of people had no idea that Python wasn't validating TLS before
2.7.9/3.4.3 however as part of the processing of changing that in 2.7.9 a lot
of people became aware that Python's before 2.7.9 didn't validate but that
Python 2.7.9+ does. I worry that if Redhat (or anyone) ships a Python 2.7.9
that doesn't verify by default then they are going to be shipping something
which defies the expectations of those users who were relying on the fact that
Python 2.7.9+ was supposed to be secure by default now. You're (understandibly)
focusing on "I already have my thing running on Python 2.7.8 and I want to
yum update and get 2.7.9 and have things not visibly break", however there is
the other use case of "I'm setting up a new environment, and I installed RHEL
and got 2.7.9, I remembered reading in LWN that 2.7.9 verifies now so I must
be safe". If you *do* provide such a switch, defaulting it to verify and having
people where that breaks go in and turn it off is probably a safer mechanism
since the cases where 2.7.9 verification breaks things for people is a visible
change where the case that someone expects 2.7.9 to verify and it doesn't isn't
a visible change and is easily missed unless they go out of their way to try
and test it against a server with an invalid certificate.

Either way, if there is some sort of global off switch, having that off switch
set to off should raise some kind of warning (like urllib3 does if you use
the unverified HTTPS methods). To be clear, I don't mean that using the built
in ssl module APIs to disable verification should raise a warning, I mean the
hypothetical "make my Python insecurely access HTTPS" configuration file (or
environment variable) that is being proposed.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150511/914483da/attachment.sig>