[Python-Dev] SSL certificates recommendations for downstreampython packagers

[Cory Benfield]

> On 2 Feb 2017, at 03:38, Stephen J. Turnbull <turnbull.stephen.fw at u.tsukuba.ac.jp> wrote:
> 
> Cory Benfield writes:
> 
>> The TL;DR is: I understand Christian’s concern, but I don’t think
>> it’s important if you’re very, very careful.
> 
> But AIUI, the "you" above is the end-user or admin of end-user's
> system, no?  We know that they aren't very careful (or perhaps more
> accurate, this is too fsckin' complicated for anybody but an infosec
> expert to do very well).

I think "you" is the coder of the interface.

From a security perspective I think we have to discount the possibility of administrator error from our threat model. A threat model that includes “defend the system against intrusions that the administrator incorrectly allows” is an insanely difficult one to respond to, given that it basically requires psychic powers to determine what the administrator *meant* instead of what they configured. Now, where we allow configuration we have a duty to ensure that it’s as easy as possible to configure correctly, but when using the system trust store most of the configuration is actually provided by the OS tools, rather than by the above-mentioned “you”, so that’s not in our control.

The risk, and the need to be very very careful, comes from ensuring that the semantics of the OS configuration are preserved through to the behaviour of the program. This is definitely a place with razor-blades all around, which is why I have tended to defer to the Chrome security team on this issue. In particular, the BoringSSL developers are razor-sharp people who have their heads screwed on when it comes to practical security decisions, and I’ve found that emulating them is usually a safe bet in the face of ambiguity.

However, it’s unquestionable that the *safest* route to go down in terms of preserving the expectations of users is to use the platform-native TLS implementation wholesale, rather than do a hybrid model like Chrome does where OpenSSL does the protocol bits and the system does the X509 bits. That way Python ends up behaving basically like Edge or Safari on the relevant platforms, or perhaps more importantly behaving like .NET on Windows and like CoreFoundation on macOS, which is a much better place to be in terms of user and administrator expectations.

As a side benefit, that approach helps take Python a bit closer to feeling “platform-native” on many platforms, which can only be a good thing for those of us who want to see more Python on the desktop (or indeed on the mobile device).

> I[1] still agree with you that it's *unlikely* that end-users/admins
> will need to worry about it.  But we need to be really careful about
> what we say here, or at least where the responsible parties will be
> looking.

I agree. In an ideal world I’d say to Steve that he should shelve his current work and wait for the TLS ABC PEP that is incoming (hopefully I’ll send a first-draft to python-dev today). However, I’m nothing if not pragmatic, and having Steve continue his current work in parallel to the TLS ABC PEP is probably a good idea so that we can avoid having all our eggs in one basket. Perhaps we can get the TLS ABC stuff in place in time for Steve to just swap over to using SChannel altogether, but if that doesn’t work out and Steve can get a halfway-house out the door earlier then that’s fine by me.

Cory