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 things. 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 want.) 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 dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
