I think that Alex and Kurt partially answered your questions.

On Wed, Oct 18, 2017 at 8:27 PM, Gregory Szorc <g...@mozilla.com> wrote:
> I'm very naive about how TLS libraries are implemented and how the TLS
> handshake works.

The basic design is that the client decides what to offer and then the
server picks.  You can decide to offer fewer options, which risks the
server having no good option to choose from.   As you suggested, you
could let the server pick from a larger set and then decide
afterwards, but that's wasteful and probably unnecessary except for
version negotiation.

As Kurt points out, version negotiation works differently (except in
TLS 1.3, but if we could rely on that being available, we wouldn't be
having this discussion).  For versions you offer version X, which
implies support for all versions up to that value.  If the server
picks a value that is too low, you have to drop the connection
afterwards.  An API for that is now commonplace in TLS stacks, but it
might not be available to you.  Patching Python to use that API isn't
an insane path to choose, but I wouldn't depend on that.

The two things you need to think about are versions and ciphersuites.
You need to think about both unfortunately, because willingness to use
particular ciphersuites can lead to version downgrades.

> 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.

If you have the option to use the OpenSSL APIs that Kurt was talking
about, that is ideal.  Tell the stack what you want and let it handle

If you want to know what a "good" configuration looks like, starting
with something like what Firefox uses is fine, but we do a few
inadvisable things in the name of compatibility, so get someone who
knows the space to review the specifics of your plan.  (The only thing
I'm aware of is that we offer a 3DES suite, which you really don't

As for downgrade, if you have a policy and stick to it, downgrade
attacks are contained.  Rule of thumb: don't change your position
about anything, especially based on stuff that you get from the
network.  Again, ask for help here to be sure.

> If you aren't able to limit the advertisement of TLS 1.0 and 1.1 protocols
> from the client, is it safe to validate the TLS-level security from
> negotiated protocol and cipher info? Is the TLS protocol version itself
> sufficient or does it need to be supplemented with e.g. a "safe" list of
> ciphers?

You definitely need a policy for both versions and ciphers.  There are
also a bunch of other recommendations here:
https://tools.ietf.org/html/rfc7525, but you will want a translator
for that.

If the only API surface you have appears after the connection is
established, as long as you don't *use* the connection (or anything
you get from it) before checking that the result is OK, then you are
safe.  We do this for HTTP/2 in Firefox; you just have to be careful
not to accidentally use the connection.
dev-tech-crypto mailing list

Reply via email to