[Python-Dev] PEP 476: Enabling certificate validation by default!
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 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.
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:
>>> 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.
You have a point there. So how about just a python run-time switch
and no env var ?
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
More information about the Python-Dev