[Security-sig] Unified TLS API for Python

Christian Heimes christian at cheimes.de
Thu Jan 12 09:24:30 EST 2017


On 2017-01-12 15:09, Nick Coghlan wrote:
> On 12 January 2017 at 22:44, Cory Benfield <cory at lukasa.co.uk> wrote:
>> We can do that.
>>
>> I should note that MINIMUM_SUPPORTED and MAXIMUM_SUPPORTED are not intended
>> to be equal to SSLv2 and TLSv1_3, or indeed to any other value in this enum.
>> They are future-proofing tools that allow users to say “I want TLSv1 *or
>> higher*” without setting an upper bound on what “higher” means.
> 
> Cool, I wasn't sure how you intended to handle that, and supplying the
> values will make it explicit that those are really only useful in
> "version_range" and not anywhere else. Although at that point the
> question becomes whether or not they're offering any benefit beyond
> just using "None" in the appropriate location.


I have a working PoC patch for a TLS version enum and set version range
method on https://bugs.python.org/issue27876.

We have to consider different kinds of min and max version:

1) min and max offical SSL/TLS standards
2) min and max supported standards for a TLS implementation
3) min and max version we consider as secure enough

As of now (1) is SSLv2 / TLSv1.2 because TLSv1.3 is still a draft.
(2) depends on the library, it is SSLv3 / TLSv1.2 for OpenSSL and SSLv3
/ TLSv1.3 for NSS on the client side and SSLv3 / TLSv1.2 for NSS on the
server side for default builds.

(3) is TLSv1.0 and max of (2).

Contrary to my PoC we should also differentiate between
MAXIMUM_SUPPORTED and whatever the maximum supported TLS version for a
TLS implementation is. For example
set_version_range(max=MAXIMUM_SUPPORTED) should never fail but
set_version_range(max=TLS_1_3) should fail for OpenSSL.

Christian


More information about the Security-SIG mailing list