EXERCISE 3 — Heartbleed remediation, and why short certs help
==============================================================

HEARTBLEED RECAP:
  A buffer over-read in OpenSSL's TLS heartbeat extension let an attacker
  read up to 64 KB of server process memory per request, with no log trace.
  That memory could contain the server's PRIVATE KEY, session cookies, and
  user credentials.

FULL REMEDIATION CHECKLIST (in order):
  1. PATCH OpenSSL to a fixed version (and restart services using it).
     -- stops further memory leaking.
  2. GENERATE A NEW PRIVATE KEY.
     -- the old key must be assumed compromised; never reuse it.
  3. REISSUE the certificate using the new key (new CSR -> new cert).
  4. REVOKE the OLD certificate (tied to the possibly-leaked key).
  5. DEPLOY the new cert + key, and ensure the server reloads them.
  6. RESET / invalidate potentially exposed secrets: user sessions
     (force re-login), and prompt password changes for affected users.

WHY PATCHING ALONE IS INSUFFICIENT:
  - Patching stops the LEAK going forward, but it does nothing about data
    already exfiltrated. If the private key leaked before patching, the
    attacker still holds it.
  - With that key an attacker can impersonate the server, and -- crucially --
    if any past sessions used NON-forward-secret key exchange (RSA key
    transport), the stolen key decrypts that previously recorded traffic
    (Chapter 3, "harvest now, decrypt later").
  - Therefore any key that MIGHT have been exposed must be treated as
    compromised: rotated, its cert reissued AND revoked. "Patched" is not
    "safe" until the key is replaced and the old cert revoked.
  - (Forward secrecy / ephemeral DH limits the blast radius: with ECDHE,
    even a leaked long-term key can't retroactively decrypt past sessions --
    a strong argument for it, Chapter 3/7.)

WHY SHORT-LIVED CERTIFICATES REDUCE RELIANCE ON REVOCATION:
  - Revocation is unreliable in practice: CRLs are stale, OCSP checks often
    "soft-fail" (browsers proceed when they can't reach the CA), and an
    attacker who can block the OCSP request can suppress the check entirely.
    So a revoked-but-not-yet-noticed cert may still be accepted by clients.
  - A short lifetime bounds the DAMAGE WINDOW directly: if a cert is valid
    for only ~90 days (or less), a compromised cert/key automatically stops
    being trusted soon, EVEN IF the revocation signal never reaches clients.
  - In effect, expiry is a revocation that always works -- it doesn't depend
    on the client successfully contacting the CA. This is why the industry
    moved to short, auto-renewed certs (Chapters 4 & 9): they make the
    weakest link (revocation) matter less.

ONE-LINE LESSON:
  Treat a possibly-leaked key as leaked: patch, rotate the key, reissue,
  revoke, reset secrets -- and rely on short cert lifetimes rather than
  trusting revocation to reach every client.