[Python-Dev] PEP 476: Enabling certificate validation by default! (original) (raw)

Antoine Pitrou solipsis at pitrou.net
Sat Aug 30 12:40:26 CEST 2014

On Sat, 30 Aug 2014 12:19:11 +0200 "M.-A. Lemburg" <mal at egenix.com> wrote:

> To add to the PEP: > > * Emit a warning in 3.4.next for cases that would raise a Exception in 3.5 > * Clearly state that the existing OpenSSL environment variables will be > respected for setting the trust root

I'd also suggest to compile Python with OPENSSLLOADCONF, since that causes OpenSSL to read the global openssl.cnf file for additional configuration.

Python links against OpenSSL as a shared library, not statically. It's unlikely that setting a compile constant inside Python would affect OpenSSL at all.

> Discussion points: > > * Disabling verification entirely externally to the program, through a CLI flag > or environment variable. I'm pretty down on this idea, the problem you hit is > that it's a pretty blunt instrument to swing, and it's almost impossible to > imagine it not hitting things it shouldn't; it's far too likely to be used in > applications that make two sets of outbound connections: 1) to some internal > service which you want to disable verification on, and 2) some external > service which needs strong validation. A global flag causes the latter to > fail silently when subjected to a MITM attack, and that's exactly what we're > trying to avoid. It also makes things much harder for library authors: I > write an API client for some API, and make TLS connections to it. I want > those to be verified by default. I can't even rely on the httplib defaults, > because someone might disable them from the outside.

The reasoning here is the same as for hash randomization. There are cases where you want to test your application using self-signed certificates which don't validate against the system CA root list.

That use case should be served with the SSL_CERT_DIR and SSL_CERT_FILE env vars (or, better, by specific settings inside the application).

I'm against multiplying environment variables, as it makes it more difficult to assess the actual security of a setting. The danger of an ill-secure setting is much more severe than with hash randomization.

Regards

Antoine.

More information about the Python-Dev mailing list