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.