[Security-sig] Unified TLS API for Python

[Christian Heimes]

On 2017-01-13 12:02, Nick Coghlan wrote:
> On 13 January 2017 at 18:27, Cory Benfield <cory at lukasa.co.uk> wrote:
>>
>>> On 13 Jan 2017, at 08:04, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>>
>>> I'd still be inclined to keep that concern separate from those of the
>>> core TLS context (which is about applying a given security context to
>>> sockets and buffers) though, and instead have the specific concept of
>>> a TLSPolicy that can be used to create TLS contexts that meet certain
>>> criteria:
>>
>> … snip ...
>>
>>> The standard library could then provide a concrete implementation and
>>> default policy that was sufficient to enforce minimum TLS versions and
>>> the acceptable cipher suites, while still leaving room for more
>>> capable third party policy enforcement.
>>
>> So, I’d like to rein this discussion in a bit here.
>>
>> The idea of being able to validate the security and correctness of a collection of TLS settings is a valuable idea. It is also vastly beyond the scope of the problem I’m trying to solve here. I want to very strongly resist the desire that a lot of the community will have to attach additional complexity and responsibility to this module. While it’s very understandable to want to do that (after all, we don’t revisit our standard library TLS functionality often), it will have the effect of chaining a concrete block to this PEP’s ankle and then throwing it into the water.
> 
> Note that I'd be reasonably happy to have my post interpreted as "We
> can leave policy definition and management until later without really
> hindering our ability to add it whenever we want to" - the only
> potential change to TLSContext would be to accept an optional "policy"
> parameter when creating instances, and that's relatively easy to add
> to implementations in a backwards compatible way (the only slight
> awkwardness lies in deciding whether or not to pass it along to base
> classes during initialization).
> 
> However, I'm also aware that one of the awkwards points in the current
> SSL module is the significant difference in behaviour between calling
> ssl.create_default_context() (good defaults) and instantiating
> ssl.SSLContext directly (bad defaults). These are two different
> SSL/TLS security policies represented as distinct SSLContext
> factories.

I'm addressing this issue with a new PEP (WIP) independently from Cory's
PEP. In 3.6 SSLContext got a bit more sane. In the future we are going
to have two protocols only (TLS_PROTOCOL_SERVER and TLS_PROTOCOL_CLIENT)
with sane default values for both contexts. Client side context will
default to cert and hostname verification, good cipher selection but no
root CA certs.

In fact I'm planning to write two PEPs, the first addresses the 'secure
by default' issue and the second addresses various issues with hostname
verification [1]. The second PEP will also require OpenSSL >= 1.0.2 and
LibreSSL >= 2.5.0, because it depends on X509_VERIFY_PARAM_set1_host().

Christian

[1]
https://speakerdeck.com/tiran/pyconpl-2016-keynote-tales-from-python-security?slide=63