On 24 Nov 2015 8:12 pm, "Paul Moore" email@example.com wrote:
On 24 November 2015 at 03:46, Nick Coghlan firstname.lastname@example.org wrote:
I think there are three relevant categories here:
- Folks who assume that "https" means the same thing in Python that
it means in web browsers, and are currently experiencing a silent security failure 2. Folks who already know it doesn't, and are relying on that to keep their infrastructure working 3. Folks currently in group 2 who would like to improve their infrastructure to default to verifying certificates
I'm not directly interested in this PEP (any code I write that is relevant will run on Windows) but there's another group:
- People who use https because it's the published API, but are only
looking at internal systems (where the threat window is minimised) and the internal infrastructure is out of their control but insecure. Browser users and other apps have to go through pain to work (accepting self-signed certs, repeatedly responding "Yes" to security warnings). Python code written for internal use just works at the moment. Maybe it "shouldn't", in some abstract sense, but it *does* and that is important to users.
This group may know that they are taking risks, and may want to improve the infrastructure, but they *can't*. And this change breaks their apps (possibly in ways they can't fix easily - not all client environments offer ways to add trust, there's a reason tools like wget have "ignore certificate checks" flags even though everyone knows they are a bad idea).
I believe you're referring mainly to the original PEP 476 change there. In the context of PEP 493, this is another group that would potentially benefit from the suggested "security downgrade" environment variable (if any redistributors decide to implement that - RHEL doesn't as yet), since it would provide a way to restore the old behaviour without changing their client code or monkeypatching the SSL module as described in PEP 476.