On 30.08.2014 12:55, Antoine Pitrou wrote:
On Sat, 30 Aug 2014 12:46:47 +0200 "M.-A. Lemburg" email@example.com wrote:
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:
Ah, ok. Do you have experience with openssl.cnf? Apparently, it is meant for offline tools such as certificate generation, I am not sure how it could impact certification validation.
I'm still exploring this: the OpenSSL documentation is, well, less than complete on these things, so searching mailing lists and reading source code appears to be the only reasonable way to figure out what is possible and what not.
The openssl.cnf config file is indeed mostly used by the various openssl subcommands (e.g. req and ca), but it can also be used to configuring engines and my hope is that configuration of e.g. default certificate stores also becomes possible.
One of the engines can tap into the Windows certificate store, for example.
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 ?
Well, why not, but does it have a value over letting the code properly configure their SSLContext?
Yes, because when Python changes the default to be validating and more secure, application developers will do the same as they do now: simply use the defaults ;-)