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

M.-A. Lemburg mal at egenix.com
Sat Aug 30 12:46:47 CEST 2014

On 30.08.2014 12:40, Antoine Pitrou wrote:

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.

The change is to the OpenSSL API, not the OpenSSL lib. By setting the variable you enable a few special calls to the config loader functions in OpenSSL when calling the initializer it:

https://www.openssl.org/docs/crypto/OPENSSL_config.html

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 SSLCERTDIR and SSLCERTFILE 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.

You have a point there. So how about just a python run-time switch and no env var ?

-- Marc-Andre Lemburg eGenix.com

Professional Python Services directly from the Source (#1, Aug 30 2014)

Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/

2014-08-27: Released eGenix PyRun 2.0.1 ... http://egenix.com/go62 2014-09-19: PyCon UK 2014, Coventry, UK ... 20 days to go 2014-09-27: PyDDF Sprint 2014 ... 28 days to go

eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

More information about the Python-Dev mailing list