✅ 09-06: TLS Best Practices & HTTPS¶
📌 A Wrap-Up Checklist¶
This lesson closes out Module 09 as a practical, reference-style checklist — pulling together the reasoning from every earlier lesson in this module into concrete actions a real server operator should take.
1️⃣ Disable Old Protocol Versions¶
Per 09-01: TLS History & Versions, SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1 all have known weaknesses (some of which are covered in 09-05: Common TLS Attacks, like POODLE and BEAST).
✔️ Do: Configure servers to only accept TLS 1.2 and TLS 1.3. ❌ Don't: Keep old versions "just in case" for legacy clients — this keeps a downgrade-attack target available indefinitely.
# Example: check what an server actually accepts using openssl
openssl s_client -connect example.com:443 -tls1
# Should FAIL to connect if TLS 1.0 is properly disabled
2️⃣ Prefer Modern Cipher Suites¶
Per 09-03: Cipher Suites, not all cipher suite components are equal.
✔️ Do: Prefer suites using ECDHE (forward secrecy) for key exchange, AES-GCM (authenticated encryption) for the bulk cipher, and SHA-256/SHA-384 for the hash. ❌ Don't: Allow RC4, static RSA key exchange (no forward secrecy — see 09-03: Cipher Suites), or SHA-1-based MACs.
💡 Forward secrecy matters operationally: if a server's long-term private key is ever stolen, connections that used an ephemeral (ECDHE) key exchange stay safe, because each session's actual encryption key was never transmitted or derivable from the long-term key alone. Static RSA key exchange doesn't have this property — one stolen key can retroactively decrypt every past captured session.
3️⃣ HSTS (HTTP Strict Transport Security)¶
HSTS is a response header a server sends to tell browsers: "always use HTTPS for this domain, for the next N seconds — never even try plain HTTP."
Why this matters¶
Without HSTS, a user typing example.com (no scheme) or clicking an old http:// link connects over plain HTTP first, and only gets redirected to HTTPS after that initial insecure request. An on-path attacker (see 03-05: MITM Attacks & Defenses) can intercept that very first plaintext request and prevent the redirect from ever happening — a technique sometimes called SSL-stripping.
With HSTS, once a browser has seen the header once, it automatically rewrites every future request to that domain as HTTPS internally, before any network traffic is even sent — so there's no plaintext first request left for an attacker to intercept.
max-age— how long (in seconds) the browser should remember this policy.includeSubDomains— apply the same rule to all subdomains.preload— allows the domain to be baked directly into browsers' shipped HSTS preload lists, protecting even a user's very first-ever visit (before the header could otherwise be seen).
4️⃣ Redirect HTTP to HTTPS¶
As a baseline (and a complement to HSTS, which only protects repeat visits or preloaded domains), servers should still redirect any incoming plain HTTP request to the HTTPS equivalent:
💡 This redirect alone doesn't stop SSL-stripping on that very first request (the redirect response itself can still be intercepted/rewritten by an attacker in the middle) — which is exactly why HSTS exists as the stronger complementary control, not a replacement.
5️⃣ Certificate Renewal & Monitoring¶
Per 09-04: Certificates in Practice, certificates expire — an expired certificate breaks every connection to the site until it's replaced.
✔️ Do: - Automate renewal (Let's Encrypt's short ~90-day validity is designed to force this — see 09-04: Certificates in Practice). - Monitor certificate expiration dates proactively (alerting well before expiry, not just discovering it when the site breaks). - Monitor Certificate Transparency logs for your domains, so you'd notice if a certificate you didn't request gets issued (a sign of a possible mis-issuance/compromise, see 09-05: Common TLS Attacks).
🧾 Quick Reference Checklist¶
| Item | Recommendation |
|---|---|
| Protocol versions | TLS 1.2 and TLS 1.3 only |
| Cipher suites | ECDHE + AES-GCM + SHA-256/384; no RC4, no static RSA key exchange |
| HSTS | Enabled, with a long max-age, includeSubDomains, ideally preload |
| HTTP traffic | Always redirect to HTTPS |
| Certificates | Automated renewal, expiration monitoring, Certificate Transparency monitoring |
| Forward secrecy | Required — ephemeral (ECDHE) key exchange only |
📌 Key Takeaways¶
- Disabling old TLS versions removes the target surface that downgrade attacks and historical exploits (POODLE, BEAST) depend on.
- Modern cipher suites should provide forward secrecy (ECDHE) and authenticated encryption (AES-GCM) — see 09-03: Cipher Suites.
- HSTS closes the gap that a plain HTTP→HTTPS redirect alone leaves open: it prevents the vulnerable first plaintext request on repeat/preloaded visits.
- Certificate renewal should be automated, not manual — expiration is a self-inflicted outage waiting to happen.
- This checklist is the practical payoff of every earlier lesson in Module 09 and much of Module 07: Cryptography Fundamentals — the theory exists specifically so it can be applied this way.