FR: Add API to get tls-unique channel binding data

[iNPUTmice]

Hi,

I’m not entirely sure if this is even possible since Java itself doesn’t have an API for this but if it is I would like to have an API to get the finish message.

The most common channel binding method for TLS is tls-unique (described in IETF RFC5929 § 3).

This is required in many context's where channel binding is desirable, including SASL authentication (SCRAM-SHA-1-PLUS requires tls-unique as the channel binding method).

The cbind data required by tls-unique is the first TLS Finished message sent in the most recent TLS handshake of the TLS connection being bound to. From RFC 5929:

Description: The first TLS Finished message sent (note: the Finished struct, not the TLS record layer message containing it) in the most recent TLS handshake of the TLS connection being bound to (note: TLS connection, not session, so that the channel binding is specific to each connection regardless of whether session resumption is used). If TLS renegotiation takes place before the channel binding operation, then the first TLS Finished message sent of the latest/ inner-most TLS connection is used. Note that for full TLS handshakes, the first Finished message is sent by the client, while for abbreviated TLS handshakes (session resumption), the first Finished message is sent by the server.

A method to retrieve the TLS Finished message would make implementing channel binding possible without resorting to custom TLS stacks.

Obviously I then would have to check if sslSocket.getSessionContext() is an instance of org.conscrypt.SessionConext or something before I can retrieve the messages. But that is still more desirable then having to replace the entire SSL stack with a different library.

[flooey]

You can use Conscrypt.getTlsUnique(socket) to access the tls-unique value. If you want to check if a socket is a Conscrypt socket you can use Conscrypt.isConscrypt(socket). Note that tls-unique isn’t supported in TLS 1.3, so you won’t be able to use those together.

[iNPUTmice]

Is implementing tls-unique for TLS 1.3 on the todo list or is this not going to be implemented at all? Apparently there were talks about deprecating it for TLS 1.3 but it doesn’t seem like we have a viable alternative channel binding method yet.

[davidben]

tls-unique indeed is not defined for TLS 1.3 at all. See https://tools.ietf.org/html/rfc8446#appendix-C.5 which explicitly states that the bindings in RFC 5929 are not defined. You should use exporters instead.

Additionally, it's likely that your use of tls-unique in TLS 1.2 is not secure. It's truncated too small. See the SLOTH attack. Additionally, if you don't require the relatively new extended master secret extension, you may have other issues per 3SHAKE.