On Wed, Oct 18, 2017 at 11:27:45AM +0200, Gregory Szorc wrote: > The way you specify the desired TLS protocol version (which is heavily > inspired by OpenSSL's API) is to pass a protocol constant along with some > more options to control ciphers, protocol options (like compression), etc. > If you want to require TLS 1.2+, you use SSLv23 and then mask out older > protocols. e.g. ssl.OP_NO_SSLv2 | ssl.OP_NO_SSLv3 | ssl.OP_NO_TLSv1 | > ssl.OP_NO_TLSv1_1.
OpenSSL 1.1.0 added a new way to do this, setting a minimum and maximum supported version, and at the same time deprecated the use of the flags. I suggest you do something like that in python too. It should be easy enough to turn the mimimum the version in a list of flags for version that don't support the minimum version. > Python versions before 2.7.9 lacked controls necessary to ensure optimal > security. For example, Python didn't expose constants to force TLS versions > >1.0. Instead, you had to use PROTOCOL_TLSv1 (the latest available > constant) and force TLS 1.0. Or, you used SSLv23 (masking out SSL v2 and v3 > of course) and hoped the underlying crypto library can negotiate TLS >1.0. Python deprecated PROTOCOL_TLSv1 since version 2.7.13. (It only allowed TLS 1.0, people have been confused by the SSLv23 name which is why OpenSSL 1.1.0 deprecated that and other names.) > Again, I'm naive, but it feels like pre-filtering is better because it > eliminates surface area for e.g. downgrade attacks. However - and this is > where the problem resides - Python <2.7.9 doesn't exactly give you the > requisite tools for adequate pre-filtering. Since the constants aren't > there, you have to use PROTOCOL_SSLv23 and "hope" that a TLS >1.0 > connection is established. The flags mentioned above did move the check for the version from python to at least OpenSSL. > Question: > > Python exposes the negotiated TLS protocol version and cipher info post TLS > handshake (results of OpenSSL's SSL_get_version() and > SSL_get_current_cipher() functions). So it is possible to examine these > values to determine whether to proceed with the connection. My question is: > what are the dangers or concerns in doing so? I'm assuming there's a > surface area of downgrade-type attacks in play. But I'm not sure the > specifics. > > e.g. on Python <2.7.9, the best we can do is use PROTOCOL_SSLv23 and "hope" > the underlying crypto library is able to negotiate TLS >1.0. But this will > advertise protocols and ciphers for TLS 1.0+ in ClientHello. I don't think > this is ideal: I think I'd prefer to not advertise client support for TLS > 1.0 (and even 1.1) support at all if there is no intent on speaking these > older (and known vulnerable) protocols. With TLS up to 1.2 you just indicate the highest supported verion, you don't have a list of supported version. With TLS 1.3 you actually send a list of versions you support, and using the minimum version (and flags) will limit the versions that are send as supported. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
