[Python-Dev] PEP 476: Enabling certificate validation by default!

Alex Gaynor alex.gaynor at gmail.com
Wed Sep 3 00:16:18 CEST 2014


Antoine Pitrou <solipsis <at> pitrou.net> writes:

> 
> And how many people are using Twisted as an HTTPS client?
> (compared to e.g. Python's httplib, and all the third-party libraries
> building on it?)
> 

I don't think anyone could give an honest estimate of these counts, however
there's two factors to bare in mind: a) It's extremely strongly recommended to
use requests to make any HTTP requests precisely because httplib is negligent
in certificate and hostname checking by default, b) We're talking about
Python3, which has fewer users than Python2.

> > Furthermore, "disable verification" is a nonsensical thing to do with TLS.
> 
> It's not. For example, if you have an expired cert, all you can do
> AFAIK is to disable verification.
> 

It really is a nonsensical operation, accepting any random TLS certificate
without pinning or use of a certificate authorities makes a valid connection
completely indistinguishable from a MITM attack.

If I were the emperor of the universe (or even just Python ;-)) I wouldn't
allow this operation at all, however, I'm not and you can still disable any and
all verification. It just requires you to pass a different argument, which
doesn't seem overly burdensome.

This whole scenario seems to be predicated on a siutation where: You have a
peer whose certificate you can't change, and you have a piece of code you can't
change, and you're going to upgrade your Python installation, and you want to
talk to this peer, and you need to use an encrypted channel, but don't really
care if it's being MITM'd. It doesn't seem to me that this is reasonably
Python's responsibility to deal with the fact that you have no ability to
upgrade any of your infrastructure, except your Python version.

Alex



More information about the Python-Dev mailing list