Re: Support tls-exporter as channel binding for TLSv1.3

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