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

[M.-A. Lemburg]

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
>> 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 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 ?

-- 
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/