Re: [Python-Dev] SSL certificates recommendations for downstream python packagers

On 30Jan2017 1310, Christian Heimes wrote:

On 2017-01-30 21:50, Cory Benfield wrote:

...

...

On 30 Jan 2017, at 13:53, David Cournapeau wrote:

Are there any official recommendations for downstream packagers beyond PEP 476 ? Is it "acceptable" for downstream packagers to patch python's default cert locations ?

There *are* no default cert locations on Windows or macOS that can be accessed by OpenSSL.

I cannot stress this strongly enough: you cannot provide a platform-native certificate validation logic for Python *and* use OpenSSL for certificate validation on Windows or macOS. (macOS can technically do this when you link against the system OpenSSL, at the cost of using a catastrophically insecure version of OpenSSL.)

In theory it is possible for Python and OpenSSL, too. I looked into a custom X509_LOOKUP_METHOD to locate trust anchors by subject. Steve is trying an alternative approach in https://bugs.python.org/issue28747. It ain't pretty and we are not there yet, too. Native support for SChannel and SecureTransport has some benefits.

My approach there is certainly not pretty, but IMHO it's the only feasible way to enable this on 3.6 (that is, until we get the proper TLS API). In short, I want to allow Python code to set OpenSSL's certificate validation callback. Basically, given a raw certificate, return True/False based on whether it should be trusted. I then have separate code (yet to be published) implementing the callback on Windows by calling into the WinVerifyTrust API with the HTTPS provider, which (allegedly) behaves identically to browsers using the same API (again, allegedly - I have absolutely no evidence to support this other than some manual testing). The big cons are that all the OpenSSL configuration you may do becomes useless (and as we know, there's essentially no configuration available for Windows's validation), and you're delegating the most interesting-to-exploit part of the process to someone else,perhaps unknowingly, if you import something that patches SSLContext... You still end up with an OpenSSL-wrapped socket, but I guess it could be with a certificate it doesn't like? (Also a big con is that Christian doesn't like this approach, and his risk assessment is certainly better than mine :) ) Native support for secure sockets is the best approach, but it won't land before 3.7. Cheers, Steve