[Python-Dev] Enable Hostname and Certificate Chain Validation

Nick Coghlan ncoghlan at gmail.com
Wed Jan 22 12:45:16 CET 2014

On 22 January 2014 21:21, Paul Moore <p.f.moore at gmail.com> wrote:
> On 22 January 2014 10:30, Donald Stufft <donald at stufft.io> wrote:
>> Python 3.4 has made great strides in making it easier for applications
>> to simply turn on these settings, however many people are not aware
>> at all that they need to opt into this. Most assume that it will operate
>> similarly to their browser, curl, wget, etc and validate by default and in
>> the typical style of security related issues it will appear to work just fine
>> however be grossly insecure.
> Two things:
> 1. To be "like the browser" we'd need to use the OS certificate store,
> which isn't the case on Windows at the moment (managing those
> certificate bundle files is most definitely *not* "like the browser" -
> I'd have no idea how to add a self-certificate to the bundle file
> embedded in pip, for example).
> 2. Your proposal is that because some application authors have not
> opted in yet, we should penalise the end users of those applications
> by stopping them being able to use unverified https? And don't forget,
> applications that haven't opted in will have no switch to allow
> unverified use. That seems to be punishing the wrong people.

Right, the browsers have a whole system of "click through" security to
make the web (and corporate intranets!) still usable even when they
only accept CA signed certs by default. With a programming language,
there's no such interactivity, so applications just break and users
don't know why.

It's notable that even Linux distros haven't made this change in their
system Python builds, and commercial Linux distros have raised
paranoia to an art form (since that's a respectable chunk of what
their users are paying for).

We also have to account for the fact that an awful lot of Python
applications are corporate ones relying on perimeter defence for
security, or private CAs, or just self-signed certificates that their
users have already accepted. There are limits to the amount of
backwards incompatible change users will tolerate, and at this point
in time we're still trying to get people to accept proper Unicode

Even the package distribution tools are struggling with the
consequences of trying to lock things down by default - every new
release of pip currently brings someone else out of the woodwork
pointing out they were relying on whichever insecure default we have
changed on them this time.

Securing the web is a "boil the ocean" type task - Python 3.4 takes us
a step closer by making it possible for people to easily use the
system certs via ssl.create_default_context()
but "move fast and break things" isn't going to work on this one any
more than it does for proper Unicode support or the IPv4 to IPv6
transition. Security concerns are too abstract for most people for
them to accept it as an excuse when you tell them you broke their
software for their own good.

The only before-Python-4 approach I can potentially see working is this:

1. Provide "ssl.create_default_context()" in 3.4 (done)
2. Deprecate the implicit SSL context in 3.5
3. Remove the implicit SSL context in 3.6
4. Make the default context the implicit context in 3.7

It would be slow, but we *could* get there. You *might* even be able
to make the case for collapsing steps 3 and 4 together so that the
more secure default is brought in as part of 3.6 in 2017.

I'd suggest a PEP along those lines, but I think you already have
plenty to keep you busy helping to ride herd on the packaging
ecosystem :)

In the meantime, making it so that it *is* just a single additional
function call to get proper TLS security settings in 3.4 is a major
step forward (thanks Christian!).


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list