[proposal] expose TLS Finished sent by the server in server and client hooks

[epoberezkin]

This message can be used as tls-unique channel binding (RFC 5929).

Possibly I missed it and it can be obtained somehow in client and server?

[kazu-yamamoto]

You can add any feature if you want.
I guess that this should be an API like getPeerFinished rather than a hook in Hooks.

[epoberezkin]

@kazu-yamamoto trying to figure out how to do it, maybe you could give me some pointers where to start...

My understanding is that you suggest a function getPeerFinished :: Context -> ByteString evaluating to Finished struct received from the peer – the actual bytes – after the connection is established, is that correct? These bytes themselves are the digest of the hadnshake, and it "should be" already validated by the library.

Context has ctxHandshake property with MVar (Maybe HandshakeState) (not sure why it's Maybe though) and HandshakeState has hstHandshakeDigest but it's probably not what I need... It's probably the digest of the sent handshake...

So I am still struggling to see where to get it from, and it seems like it's just not there yet, and something should put it there.

Anyway, any suggestions/help would be great...

[epoberezkin]

Some other possible relevant places:

• doHandshake13 and postHandshakeAuthServerWith - seems to be for TLS 1.3 that I need - both seem to check Finished
• processClientFinished that compares actual Finished with expected - I believe it runs in the server - it could be putting Finished inside Context - possibly some Maybe property that's initially Nothing - and getPeerFinished would retrieve it.

[kazu-yamamoto]

I would suggest getPeerFinished :: Context -> IO (Maybe ?) where ? is up to you. You can store wire-bytes or decrypted one or what ever you want.

You should define one field of IORef (Maybe ?) in Context whose initial value is Nothing. getPeerFinished just reads the IORef.

If ? is FinishedData, it is easy to store it in every handler. You can find the handlers by grep -r Finished Network . If ? is wire-bytes, I guess that you should encode Finished into wire-bytes again. This seems redundant but I grantee that it works well.

[kazu-yamamoto]

hstHandshakeDigest stores all handshake messages of wire-bytes. If it gets full, it is converted a hash value to be compared with FinishedData.

[kazu-yamamoto]

Instead of Context directly, I guess you can add hstPeerFinished in HandshakeState. I don't have strong preference.

[epoberezkin]

Hi @kazu-yamamoto - please have a look at #445

[Neustradamus]

Any progress on it?

I think that you have seen the jabber.ru MITM and Channel Binding is the solution:

• https://notes.valdikss.org.ru/jabber.ru-mitm/
• https://snikket.org/blog/on-the-jabber-ru-mitm/
• https://www.devever.net/~hl/xmpp-incident
• https://blog.jmp.chat/b/certwatch

Little details, to know easily:

• tls-unique for TLS =< 1.2
• tls-server-end-point
• tls-exporter for TLS = 1.3

Thanks in advance.

Linked to:

• State of Play scram-sasl/info#1
• add getFinished and getPeerFinished functions for Context, closes #442 #445
• RFC 9266: Channel Bindings for TLS 1.3 support #462

[kazu-yamamoto]

Closing because #445 is already merged and in favor of #462.