What actually does the TLS 1.3 Finished message protect, and how?

What actually does the TLS 1.3 Finished message protect, and how?

This is the handshake's self-defense mechanism, and reading it precisely dispels the idea that the certificate signature alone secures the negotiation.

During a handshake, many parameters are exchanged in plaintext or under provisional keys: offered versions, cipher suites, extensions, key shares. An active attacker could try to tamper with any of these. The certificate's signature authenticates the server's identity, but on its own it does not bind the entire negotiated context.

The Finished message (RFC 8446 §4.4.4) closes that gap. Each side computes a running hash over the complete handshake transcript — every message sent and received, in order. It then computes an HMAC over that transcript hash using a finished_key derived via HKDF from its handshake traffic secret. The peer recomputes the same value; any mismatch aborts the connection.

The consequence is strong: if an attacker altered even one byte of any handshake message — downgrading a cipher, stripping an extension, swapping a key share — the two sides' transcript hashes diverge, the Finished MACs don't match, and the handshake fails before application data flows. This is what makes the entire negotiation tamper-evident, not just the identity assertion.

It also ties the keys to the transcript: the same exchange under a different transcript yields different keys, frustrating cross-protocol and reflection attacks.

Further reading: RFC 8446 §4.4.4, §7.1 (key schedule).

Bottom line: the Finished message HMACs the full handshake transcript, making every negotiated parameter tamper-evident — the certificate proves who, the Finished proves the negotiation itself wasn't altered.