[Python-Dev] PEP 476: Enabling certificate validation by default!
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 OPENSSL_LOAD_CONF, since that
> causes OpenSSL to read the global openssl.cnf file for additional
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.
More information about the Python-Dev