On 14 January 2017 at 02:20, Christian Heimes <christ...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Security-SIG mailing list Security-SIG@python.org https://mail.python.org/mailman/listinfo/security-sig
