EXERCISE 3 — A downgrade attack and why Finished defeats it
============================================================

THE ATTACK ATTEMPT:
  - The ClientHello is sent in the CLEAR and lists every cipher suite the
    client supports, strongest first.
  - A man-in-the-middle intercepts it and EDITS the cipher list, deleting
    the strong/modern suites and leaving only a weak, breakable one — hoping
    the server will then "agree" to weak crypto the attacker can crack.

TRACE OF WHAT HAPPENS:
  1. Server receives the tampered ClientHello, sees only the weak suite,
     and selects it in ServerHello. So far the attack seems to be working.
  2. The handshake proceeds; eventually BOTH sides send a Finished message.
  3. Finished contains a hash (a MAC, keyed by the freshly derived session
     keys) of the ENTIRE handshake transcript each side observed --
     including the ClientHello.
        - The CLIENT's Finished is computed over the ORIGINAL ClientHello
          it actually sent (with the strong suites).
        - The SERVER's Finished is computed over the TAMPERED ClientHello
          it received (strong suites removed).
  4. The two transcripts DIFFER, so the two Finished hashes DON'T MATCH.
     When each side checks the other's Finished against its own transcript
     view, verification FAILS.

WHICH MESSAGE CAUSES THE ABORT:
  - The Finished message. The mismatch is detected when Finished is
    verified, and the connection is torn down with a handshake_failure /
    bad_record_mac alert BEFORE any application data is sent.

WHY THE ATTACKER CAN'T COVER THEIR TRACKS:
  - To make the Finished hashes agree, the attacker would have to forge a
    valid Finished MAC matching one side's tampered transcript. But the
    Finished MAC is keyed by the SESSION KEYS, which are derived from the
    ECDHE pre-master secret the attacker does NOT possess (they couldn't
    inject their own DH value either — see Exercise 2).
  - So the attacker can tamper with the cleartext early messages, but
    cannot produce the matching Finished, and cannot hide the discrepancy.
  - The handshake effectively validates its OWN integrity retroactively:
    everything said in the clear is sealed by the Finished hash once keys
    exist.

TAKEAWAY:
  Sending early handshake messages in the clear is safe specifically
  because Finished binds the whole transcript. (TLS 1.3 adds further
  explicit downgrade-protection signaling on top of this — Chapter 7.)