On Wed, Aug 31, 2022 at 04:16:29PM -0700, Jacob Champion wrote: > For protocols less than 1.3 we'll need to ensure that the extended > master secret is in use: > > This channel binding mechanism is defined only when the TLS handshake > results in unique master secrets. This is true of TLS versions prior > to 1.3 when the extended master secret extension of [RFC7627] is in > use, and it is always true for TLS 1.3 (see Appendix D of [RFC8446]). > > OpenSSL should have an API for that (SSL_get_extms_support); I don't > know when it was introduced.
This is only available from 1.1.0, meaning that we'd better disable tls-exporter when building with something older than that :( With 1.0.2 already not supported by upstream even if a bunch of vendors keep it around for compatibility, I guess that's fine as long as the default setting is tls-server-end-point. It would not be complex to switch to tls-exporter by default when using TLSv1.3 and tls-server-end-point for TLS <= v1.2 though, but that makes the code more complicated and OpenSSL does not complain with tls-exporter when using < 1.3. If we switch the default on the fly, we could drop channel_binding_type and control which one gets used depending on ssl_max/min_server_protocol. I don't like that much, TBH, as this creates more dependencies across our the internal code with the initial choice of the connection parameters, making it more complex to maintain in the long-term. At least that's my impression. > If we want to cross all our T's, we should also disallow tls-exporter > if the server was unable to set SSL_OP_NO_RENEGOTIATION. Hmm. Okay. I have not considered that. But TLSv1.3 has no support for renegotiation, isn't it? And you mean to fail hard when using TLS <= v1.2 with tls-exporter on the backend's SSL_CTX_set_options() call? We cannot do that as the backend's SSL context is initialized before authentication, but we could re-check the state of the SSL options afterwards, during authentication, and force a failure. > Did you have any thoughts about contributing the Python tests (or > porting them to Perl, bleh) so that we could test failure modes as > well? Unfortunately those Python tests were also OpenSSL-based, so > they're less powerful than an independent implementation... No. I have not been able to look at that with the time I had, unfortunately. -- Michael
signature.asc
Description: PGP signature