[Python-Dev] Enable Hostname and Certificate Chain Validation (original) (raw)

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 support.

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() (http://docs.python.org/dev/library/ssl.html#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!).

Cheers, Nick.

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

More information about the Python-Dev mailing list