[Python-Dev] Request for pronouncement on PEP 493 (HTTPS verification backport guidance)

Paul Moore p.f.moore at gmail.com
Tue Nov 24 05:12:10 EST 2015


On 24 November 2015 at 03:46, Nick Coghlan <ncoghlan at gmail.com> wrote:
> I think there are three relevant categories here:
>
> 1. 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:

4. 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).

The push for "secure by default" is important and needed, but needs to
be handled in a more pragmatic way, recognising that Python is used in
situations like the above, where people know they aren't doing the
right thing, but have no better options. Shutting down their least bad
option on a point of principle isn't helpful.

Paul


More information about the Python-Dev mailing list