Re: Security implications for TLS validation post handshake

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
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto