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

[Steve Dower]

On 30Jan2017 1310, Christian Heimes wrote:
> On 2017-01-30 21:50, Cory Benfield wrote:
>>
>>
>>> On 30 Jan 2017, at 13:53, David Cournapeau <cournape at gmail.com> 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