EXERCISE 1 — Spotting ECDHE in a real handshake
================================================

Command:
  openssl s_client -connect example.com:443 </dev/null

(The </dev/null sends an empty request so the command returns instead of
hanging waiting for input.)

Relevant lines in the output:
  ...
  Server Temp Key: X25519, 253 bits
  ...
  New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
  ...
  Protocol  : TLSv1.3
  Cipher    : TLS_AES_256_GCM_SHA384

HOW TO READ IT:
  - "Server Temp Key: X25519" is the giveaway. A *Temp* (temporary /
    ephemeral) key means the server generated a one-time Diffie-Hellman
    key for THIS session. X25519 is a modern elliptic curve -> this is
    ECDHE (Elliptic Curve Diffie-Hellman EPHEMERAL).
  - In TLS 1.3, ECDHE is the ONLY key-exchange option, so every 1.3
    connection has a Server Temp Key line.
  - On a TLS 1.2 server you would instead see a cipher name that spells
    it out, e.g. ECDHE-RSA-AES256-GCM-SHA384:
        ECDHE = ephemeral EC Diffie-Hellman key exchange
        RSA   = the certificate signature type (authentication)
        AES256-GCM = the symmetric AEAD cipher for the data
        SHA384 = hash used in the handshake

WHAT THE "E" GUARANTEES:
  - The E = Ephemeral: the key-exchange private value is freshly made for
    this one session and thrown away afterwards. That is exactly what
    provides FORWARD SECRECY — if the server's long-term key is stolen
    later, this session's traffic still can't be decrypted, because the
    ephemeral value that protected it no longer exists.

TIP: to confirm forward secrecy, the presence of "Server Temp Key" (a
temporary/ephemeral key) is the thing to look for. A handshake with no
temp key (old RSA key transport) would lack that line.