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

Donald Stufft donald at stufft.io
Wed Jan 22 13:15:47 CET 2014

On Jan 22, 2014, at 6:58 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

On 22 January 2014 21:36, Donald Stufft <donald at stufft.io> wrote:

On Jan 22, 2014, at 6:30 AM, M.-A. Lemburg <mal at egenix.com> wrote:

The change would also disable all services using self-signed certificates which are very common in internal networks and for ad-hoc setups. Many routers and other devices use self-signed certificates when offering HTTPS services.

It will just disable them by default, they can still easily be accessed you’d just need to pass the “do not verify” flag. This clearly indicates that you’re opting out of the S in HTTPS. You need to remember that *Python is fundamentally not an application*. We don't control the interaction with the user, application developers do, and every decision we make has to take that into account. The kinds of decisions that an application like a web browser or a package installer can make aren't necessarily available to a runtime. We had to be cautious even with the initial hash randomisation change to avoid breaking currently working applications.

The same could be said for requests, it’s fundamentally not an application and can’t control the interaction with the user and yet it validates TLS by default just fine.

Look at the anger that people express about us making Python 3 more sensitive to environment misconfiguration on POSIX systems: people don't blame the misconfigured environment that Python 2 tolerated with an increased risk of data corruption, they blame us for breaking something that used to work by default.

They blame Python for breaking something that used to work by default for something they feel has little or no benefit, and which is also difficult or impossible to adapt to without often significant code changes (for the people who I’ve seen blaming Python dev for).

Do you really think those people would be making the same complaints if they could restore the previous behavior with a simple boolean flag delivered either via environment variable or in their own code?

The change you're proposing would mean that every Python application would either need to be updated to explicitly opt in to insecurity (the path most of them will take, because humans) or else to provide a "set this option to make your computer work again" insecurity flag (which is a bad idea anyway, again because humans).

Every Python application that depends on an invalid certificate and is written for Python3. It’s not hardly every Python application since a good majority of them will simply continue working, and given that most Python applications are still written for Python2 it’s not even something that is going to affect the bulk of Python applications.

There are currently still too many valid reasons for not using verified SSL for us to realistically make it the default without a seriously long transition period (not quite IPv6 or even Python 3 long, but certainly not as short as the time period involved in introducing hash randomisation).

As I’ve said multiple times, I think it’s fine to send it through the deprecation process which is still pretty long and gives people a good chunk of time to update.

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

Donald Stufft PGP: 0x6E3CBCE93372DCFA // 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/20140122/d8f0d791/attachment.sig>

More information about the Python-Dev mailing list