[Security-sig] Unified TLS API for Python

[Nick Coghlan]

On 14 January 2017 at 02:20, Christian Heimes <christian at cheimes.de> wrote:
> There aren't many settings that are truly implementation independent.
> Even ciphers depend on the implementation and version of the TLS
> provider. Some implementations do support more or less ciphers. Some
> allow ordering or black listing of algorithms, some do not. Apparently
> it's even hard to not use the system trust store in some implementations
> (SecureTransport). How should we deal with e.g. when a TLS
> implementation does not accept or now about a cipher?

That problem is one we're going to have to resolve regardless, and
could potentially become its own configuration setting.

> I would rather invest time to make TLSConfiguration optional for 99% of
> all users. Unless you need to connect to a crappy legacy device, a user
> or developer should not need to mess with TLS settings to get secure
> options. Some TLS libraries already set sane defaults. OpenSSL is
> getting there, too. Browsers get it right as well.

Sure, but there are also plenty of folks that *are* going to need to
tinker with those settings:

- stdlib maintainers
- folks writing TLS servers
- folks writing TLS client libraries
- folks writing test cases for TLS servers
- folks writing test cases for TLS clients
- penetration testers
- network security researchers
- folks integrating with legacy infrastructure
- embedded software developers
- etc

We want to provide those folks with a reasonable learning curve as
they move away from "the defaults are good enough for me" to "I need
to make these changes, for these reasons", even as we attempt to make
sure that "routine" use cases are secure by default.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia