EXERCISE 2 — How the signed ServerKeyExchange stops a MITM
===========================================================

THE SETUP:
  In ECDHE, the server sends its ephemeral Diffie-Hellman PUBLIC value in
  the ServerKeyExchange message. On its own, a DH public value carries no
  identity (Chapter 3) — so a man-in-the-middle could try to replace the
  server's DH value with their OWN, do separate DH exchanges with each
  side, and sit in the middle decrypting/re-encrypting.

WHAT ACTUALLY HAPPENS, STEP BY STEP:
  1. The server signs its DH value:
         signature = Sign(server_private_key,
                          client_random + server_random + server_DH_public)
     The signature covers the DH value AND both randoms (so it can't be
     replayed from a different session).
  2. The client has ALREADY verified the server's CERTIFICATE in Step 3,
     and confirmed it chains to a trusted root and matches the hostname.
     So the client trusts the PUBLIC KEY inside that certificate.
  3. The client verifies the ServerKeyExchange signature using that
     certificate public key:
         Verify(cert_public_key, signature) -> must be valid.
  4. A valid signature proves the DH value was produced by the holder of
     the certificate's PRIVATE key — i.e. the authenticated server.

WHY THE MITM FAILS:
  - If the attacker swaps in their own DH value, they must also produce a
    signature over it that verifies against the REAL server's certificate
    public key.
  - To do that they'd need the server's PRIVATE key, which they don't have
    (it never leaves the server).
  - If they instead present their OWN certificate, it won't chain to a
    trusted root for the right hostname -> Step 3 authentication fails.
  - Either way the handshake aborts. The signature welds the ephemeral key
    to the authenticated identity.

WHICH EARLIER STEP THE SIGNATURE DEPENDS ON:
  - Step 3, the Certificate message. The signature is only meaningful
    because the client first verified the certificate (and thus the public
    key it uses to check the signature) chains to a trusted CA.

WHAT THE ATTACKER WOULD NEED TO FORGE IT:
  - The server's long-term PRIVATE key, OR
  - A fraudulently issued certificate for the domain that chains to a root
    in the victim's trust store (the scenario Certificate Transparency,
    Chapter 12, is designed to detect).