In SSL 3.0 and TLS versions 1.0 through 1.2 the last two messages are the "Client Finished" followed by "Server Finished" messages. These messages include an encrypted (under the established session keys) MAC of all the previous messages.

However, in TLS 1.3 and in the abbreviated handshake, the server is the first to send a "Finished" message, not the client.

I'm trying to understand if the order has some significance in regards to security, but I believe the answer is no. Replay attacks are not possible because of the nonce values, and MITM attacks (that would be impossible because pre_master_secret is encrypted under the server's public key and used by the client to establish keys) would rely on the attacker establishing keys with both client and server, which wouldn't matter when it comes to who sends the finished message first.

My question is, does it matter from a security point of view whether the client or the server are the first to send the message? What's the rationale behind the changing order?

  • 1
    $\begingroup$ I don't think so, but I didn't yet get to the finished part of the TLS protocol when implementing it. Finished message themselves do matter because it is unclear what data - if any - is going to be send - and you do want to make sure that you've established the same session keys using valid parameters. I've seen protocols that implemented implicit authentication, and that ain't pretty. In the end this is about symmetric keys, I guess which one goes first ultimately doesn't matter for those. $\endgroup$ – Maarten Bodewes Feb 29 at 0:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.