EXERCISE 3 — Classify each suite: MODERN-SAFE or AVOID
=======================================================

(a) TLS_AES_128_GCM_SHA256
    MODERN-SAFE.
    A TLS 1.3 suite. Key exchange is always ephemeral (EC)DHE and the
    cipher is AES-128-GCM (AEAD). Forward secrecy is mandatory, integrity
    is built in. Nothing to improve — this is exactly what you want.

(b) ECDHE-RSA-AES128-GCM-SHA256
    MODERN-SAFE.
    TLS 1.2 suite, but a good one: ECDHE = forward secrecy, RSA cert for
    auth, AES-128-GCM = AEAD cipher, SHA256 hash. This is the recommended
    1.2 baseline.

(c) AES256-SHA   (= TLS_RSA_WITH_AES_256_CBC_SHA)
    AVOID.
    Two problems, and the BIGGEST is: the key exchange is plain RSA key
    transport (no ECDHE) -> NO FORWARD SECRECY. If the server's key is ever
    stolen, all past recorded sessions can be decrypted ("harvest now,
    decrypt later", Chapter 3). Secondary problem: AES-CBC + SHA1 is a
    non-AEAD MAC-then-encrypt mode vulnerable to padding-oracle attacks
    (Lucky13/BEAST family). Disable.

(d) ECDHE-RSA-RC4128-SHA
    AVOID.
    It DOES have ECDHE (forward secrecy), so that part is fine — but the
    BIGGEST problem is the bulk cipher: RC4. RC4 has known keystream biases
    and is cryptographically broken; it was formally prohibited in TLS.
    Good key exchange can't rescue a broken cipher. Disable.

SUMMARY TABLE:
  suite                          verdict       single biggest problem
  -----                          -------       ----------------------
  TLS_AES_128_GCM_SHA256         MODERN-SAFE   (none)
  ECDHE-RSA-AES128-GCM-SHA256    MODERN-SAFE   (none)
  AES256-SHA                     AVOID         RSA kex -> no forward secrecy
  ECDHE-RSA-RC4128-SHA           AVOID         RC4 is a broken cipher

RULE OF THUMB APPLIED:
  Want forward secrecy -> need ECDHE/DHE at the front (rules out c).
  Want a safe cipher    -> need GCM or CHACHA20-POLY1305, not CBC/RC4/3DES
                           (rules out c and d).
  Pass both -> modern-safe (a and b).