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

[David Cournapeau]

On Tue, Jan 31, 2017 at 9:19 AM, Cory Benfield <cory at lukasa.co.uk> wrote:

>
> On 30 Jan 2017, at 21:00, David Cournapeau <cournape at gmail.com> wrote:
>
>
>
> On Mon, Jan 30, 2017 at 8:50 PM, Cory Benfield <cory at lukasa.co.uk> 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.)
>>
>
> Ah, thanks, that's already useful information.
>
> Just making sure I understand: this means there is no way to use python's
> SSL library to use the system store on windows, in particular private
> certifications that are often deployed by internal ITs in large orgs ?
>
>
> If only it were that simple!
>
> No, you absolutely *can* do that. You can extract the trust roots from the
> system trust store, convert them into PEM/DER-encoded files, and load them
> into OpenSSL. That will work.
>

Right, I guess it depends on what one means by "can". In my context, it was
to be taken as "can it work without the end user having to do anything". We
provide them a python-based tool, and it has to work with the system store
out of the box. If the system store is updated through e.g. group policy,
our python tool automatically get that update.

>From the sound of it, it looks like this is simply not possible ATM with
python, at least not without 3rd party libraries.

David


> The problem is that both SecureTransport and SChannel have got a number of
> differences from OpenSSL. In no particular order:
>
> 1. Their chain building logic is different. This means that, given a
> collection of certificates presented by a server and a bundle of
> already-trusted certs, each implementation may build a different trust
> chain. This may cause one implementation to refuse to validate where the
> others do, or vice versa. This is very common with older OpenSSLs.
> 2. SecureTransport and SChannel both use the system trust DB, which on
> both Windows and mac allows the setting of custom policies. OpenSSL won’t
> respect these policies, which means you can fail-open (that is, export and
> use a root certificate that the OS believes should not be trusted for a
> given use case). There is no way to export these trust policies into
> OpenSSL.
> 3. SecureTransport, SChannel, and OpenSSL all support different X.509
> extensions and understand them differently. This means that some certs may
> be untrusted for certain uses by Windows but trusted for those uses by
> OpenSSL, for example.
>
> In general, it is unwise to mix trust stores. If you want to use your OS’s
> trust store, the best approach is to use the OS’s TLS stack as well. At
> least that way when a user says “It works in my browser”, you know it
> should work for you too.
>
> Cory
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20170131/de284137/attachment-0001.html>