On Sun, Aug 28, 2022 at 11:02 PM Michael Paquier <michael@paquier.xyz> wrote:
> RFC9266, that has been released not so long ago, has added
> tls-exporter as a new channel binding type:
> https://www.rfc-editor.org/rfc/rfc5929.html
Hi Michael, thank you for sending this!
> Note also that tls-exporter is aimed for
> TLSv1.3 and newer protocols, but OpenSSL allows the thing to work with
> older protocols (testable with ssl_max_protocol_version, for example),
> and I don't see a need to prevent this scenario.
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.
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.
> An extra thing is
> that attempting to use tls-exporter with a backend <= 15 and a client
> >= 16 causes a failure during the SASL exchange, where the backend
> complains about tls-exporter being unsupported.
Yep.
--
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...
Thanks,
--Jacob
