Is it possible to configure pyopenssl to negotiate TLS-1.2-or-worse?

[njsmith]

Yeah, that's not a typo...

I have a TLS transport implementation. It has tests. One of the things the tests spend a lot of effort on is checking that renegotiation is handled correctly.

In TLS 1.3, renegotiation has been removed from the protocol. For reasons that careful readers may be able to infer from the previous paragraph, I think this is a great idea. However, renegotiation has one last "f you" for me: this is going to break my test suite, because once TLS 1.3 support ships then my renegotiation tests will start negotiating 1.3 and then blow up when I try to do explicit renegotiations. (I'm pretty sure. I guess there's also some chance that they'll seem to work but actually not test anything. Just the kind of thing we like in our security-sensitive code.)

At first I thought I could avoid this by using PROTOCOL_TLS_v1_2, but then my tests fail on py35 + MacOS because the code I'm trying to test uses stdlib ssl, and because Apple hates security and wants me to suffer.

So really what I want is a way to say "negotiate whatever you want, as long as it's 1.2 or worse". Is that possible? I see SSL_CTX_set_max_proto_version in the openssl manual, but in the pyopenssl docs I only see the OP_NO_* constants. I guess I could make those work, but then I have a timebomb where my tests will break when 1.4 is released. Which admittedly is not likely to happen anytime soon, but it makes me itch a bit. Or I guess I could just not test on MacOS b/c if Apple hates security then who am I to argue...?

[tiran]

SSL_CTX_set_max_proto_version() is OpenSSL 1.1.0+. It's not available in 1.0.2 and earlier. In order to allow TLS 1.0, 1.1 and 1.2, do

• use PROTOCOL_SSLv23
• set flags OP_NO_SSLv2 | OP_NO_SSLv3 | getattr(module, 'OP_NO_TLSv1_3', 0)

I'm going to add the flag to Python soon, https://bugs.python.org/issue29136 . @hynek can add the flag to PyOpenSSL as soon it is available in cryptography.

[njsmith]

As mentioned, the OP_NO_* flags are an option, but make me a little nervous because of the lack of future-proofing. Maybe I'm overthinking this... Are the cryptography wheels shipping openssl 1.1 yet? I'm not too worried if my test suite needs a recent version of tls...

though hmm, reading bpo-29136 gives me an idea: I could set an explicit list of allowed ciphers, and that will implicitly prevent TLS1.3+ from being negotiated :-)

[alex]

Yes, we ship 1.1 in our wheels. I recommend going with just the `OP_NO` flags, TLS 1.4 isn't going to happen for a longass time, I wouldn't make any design decisions based on it.

…

On Sat, Apr 29, 2017 at 5:26 PM, Nathaniel J. Smith < ***@***.***> wrote: As mentioned, the OP_NO_* flags are an option, but make me a little nervous because of the lack of future-proofing. Maybe I'm overthinking this... Are the cryptography wheels shipping openssl 1.1 yet? I'm not too worried if my test suite needs a recent version of tls... though hmm, reading bpo-29136 gives me an idea: I could set an explicit list of allowed ciphers, and that will implicitly prevent TLS1.3+ from being negotiated :-) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#624 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAADBGD0B_lRYr2Q6zOk2Nk7IEesae1Wks5r06r1gaJpZM4NMYDo> .

-- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: D1B3 ADC0 E023 8CA6

[tiran]

@njsmith No, a restricted cipher list won't prevent TLS 1.3. I've done some experiments with OpenSSL master, NSS and mod_nss in the past. Libraries will prefer TLS 1.3 if both sides have TLS 1.3 enabled. Without TLS 1.3 cipher suites, cipher suite negotiation fails and the connection is aborted.