On 2017-01-13 16:45, Nick Coghlan wrote: > On 13 January 2017 at 23:56, Cory Benfield <c...@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 _______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig
