On 2014年8月30日 12:19:11 +0200 "M.-A. Lemburg" <[email protected]> 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. _______________________________________________ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com