[Security-sig] Unified TLS API for Python

[Christian Heimes]

On 2017-01-13 16:45, Nick Coghlan wrote:
> On 13 January 2017 at 23:56, Cory Benfield <cory at lukasa.co.uk> wrote:
>> While we’re here, I should point out that this does not replace the abstract
>> contexts entirely, because we still need the wrap_* methods. These would now
>> just be fed a Configuration object (I’m more comfortable with the name
>> Configuration than Policy for this usage) in their constructor, and then
>> could use the wrap_* methods as needed.
> 
> Having a relatively passive configuration object sounds OK to me, and
> I agree it's distinct from a Policy object (which would store
> constraints on what an acceptable configuration looks like, rather
> than a specific configuration).
> 
>> How does that idea sound to the rest of the list?
> 
> It would definitely address my concern about making it easy for people
> to re-use the standard library's default TLS configuration settings,
> and it would also make it easier to have different defaults for
> different purposes.
> 
> So the essential stack would look like:
> 
>   TLSConfig[uration?]: implementation independent, settings only
>   TLSClientContext: ABC to combine settings with a specific TLS implementation
>   TLSServerContext: ABC to combine settings with a specific TLS implementation
>   TLSSocket: ABC to combine a context with a network socket
>   TLSBuffer: ABC to combine a context with a pair of data buffers
> 
> And then TLSPolicy would be a potential future implementation
> independent addition that could be used to constrain acceptable TLS
> configurations.

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?

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.

Even for OpenSSL 1.0.2 (first 1.0.2 release) it is possible to set a
secure and future proof cipher list:

[openssl/1.0.2]$ bin/openssl ciphers
'DEFAULT:!3DES:!EXPORT:!RC4:!DES:!MD5:!SRP:!PSK:!IDEA:!SEED' | sed
's/:/\n/g'
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-SHA
ECDHE-ECDSA-AES256-SHA
DH-DSS-AES256-GCM-SHA384
DHE-DSS-AES256-GCM-SHA384
DH-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-SHA256
DHE-DSS-AES256-SHA256
DH-RSA-AES256-SHA256
DH-DSS-AES256-SHA256
DHE-RSA-AES256-SHA
DHE-DSS-AES256-SHA
DH-RSA-AES256-SHA
DH-DSS-AES256-SHA
DHE-RSA-CAMELLIA256-SHA
DHE-DSS-CAMELLIA256-SHA
DH-RSA-CAMELLIA256-SHA
DH-DSS-CAMELLIA256-SHA
ECDH-RSA-AES256-GCM-SHA384
ECDH-ECDSA-AES256-GCM-SHA384
ECDH-RSA-AES256-SHA384
ECDH-ECDSA-AES256-SHA384
ECDH-RSA-AES256-SHA
ECDH-ECDSA-AES256-SHA
AES256-GCM-SHA384
AES256-SHA256
AES256-SHA
CAMELLIA256-SHA
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-SHA256
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES128-SHA
ECDHE-ECDSA-AES128-SHA
DH-DSS-AES128-GCM-SHA256
DHE-DSS-AES128-GCM-SHA256
DH-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-SHA256
DHE-DSS-AES128-SHA256
DH-RSA-AES128-SHA256
DH-DSS-AES128-SHA256
DHE-RSA-AES128-SHA
DHE-DSS-AES128-SHA
DH-RSA-AES128-SHA
DH-DSS-AES128-SHA
DHE-RSA-CAMELLIA128-SHA
DHE-DSS-CAMELLIA128-SHA
DH-RSA-CAMELLIA128-SHA
DH-DSS-CAMELLIA128-SHA
ECDH-RSA-AES128-GCM-SHA256
ECDH-ECDSA-AES128-GCM-SHA256
ECDH-RSA-AES128-SHA256
ECDH-ECDSA-AES128-SHA256
ECDH-RSA-AES128-SHA
ECDH-ECDSA-AES128-SHA
AES128-GCM-SHA256
AES128-SHA256
AES128-SHA
CAMELLIA128-SHA