1
$\begingroup$

I cannot quite understand, if Finished message serves any particular purpose when the server is being authenticated via certificates, or if it there just for "consistency" or "extra protection".

The Finished message is said to provide integrity of the entire handshake and computed keys. But when authenticated via certificate there is also CertificateVerify message which does it as well, as it looks to me.

  • If the attacker changes something in the handshake (like a cipher suite or someone's key share), then the handshake transcript will be different for client and the server, so client won't be able to verify the Signature in CertificateVerify.
  • Even if the attacker is able to somehow screw up key computations while preserving transcript hash, the signature from CertificateVerify will be valid (since it is computed over transcript hash), but the client won't be able to verify it, since CertificateVerify is encrypted with AEAD, so when decrypting it the MAC which is provided by AEAD will not match. Even if it matches somehow, the decrypted signature will be different from the one computed by the server (because of key mismatch) and so it will be invalid.
  • Even if there is an implementation error on the client/server and some keys are computed incorrectly, the same problem occurs: MAC from AEAD will not match on encrypted record and decrypted signature will differ from the one computed by server.

It looks to me as if Finished message is useful when using other key exchange methods, where CertificateVerify is not sent, but in this scenario it exists just for consistency. Am I right? Or is there some scenario, some way how the attacker may intervene, so that signature from CertificateVerify is valid, but MAC from Finished is not?

There is a similar question, but I didn't find a satisfying answer there.

$\endgroup$
3
  • $\begingroup$ Interesting observation. I'd say that it is hard to create an authentication error when doing message decryption in an architectural sense. But in this case the established keys are already being used. Note though that the MAC is over the entire handshake and may therefore offer additional protection on top of verifying that both parties have the same key. $\endgroup$
    – Maarten Bodewes
    Commented Oct 4, 2023 at 11:14
  • $\begingroup$ The MAC is there for a security reason. It is used to provide what is sometimes called "consistency". I will develop later in an answer but, sadly, "authentication" in Authenticated Key Exchanges is understood as "knowing the identity" of the peer. But what is overlooked is authenticating the session key. Failing to do so leads to some subtle attacks like identity misbinding attacks. More to come later and how it related to TLS1.3. $\endgroup$ Commented Oct 4, 2023 at 15:22
  • $\begingroup$ @MarcIlunga, hello, do you have any updates? $\endgroup$
    – jabuj
    Commented Oct 7, 2023 at 5:37

1 Answer 1

1
$\begingroup$

I cannot quite understand, if Finished message serves any particular purpose

All records up to the Finished message are encrypted with one key (derived from handshake_traffic_secret). All records after that are encrypted with a different key (derived from application_traffic_secret).

Hence, at the very least, it needs to be there to tell the other side when to switch encryption keys.

$\endgroup$
1
  • $\begingroup$ That makes sense. I should probably have phrased the question "Does the MAC from the Finished message serve any purpose", this is the real deal :) $\endgroup$
    – jabuj
    Commented Oct 4, 2023 at 14:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.