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

[Antoine Pitrou]

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 OPENSSL_LOAD_CONF, 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.