Skip to content

⚔️ 09-05: Common TLS Attacks

📌 Why TLS Gets Attacked

TLS is the thing standing between an eavesdropper/on-path attacker (see 03-05: MITM Attacks & Defenses) and your plaintext traffic. Attackers who can position themselves on the network path can't usually break the math behind AES or RSA directly (see Module 07: Cryptography Fundamentals) — instead, they attack the protocol, the implementation, or the trust model around TLS. This lesson covers the main categories.

⬇️ Downgrade Attacks

A downgrade attack tricks two parties who both support strong, modern TLS into negotiating a weaker, older, breakable configuration instead.

How the negotiation normally works

During the handshake (see 09-02: The TLS Handshake), the client's ClientHello lists every TLS version and cipher suite it supports, and the server picks the strongest option both sides support.

How an attacker interferes

An on-path attacker who can modify handshake traffic (before encryption is established — the very first messages are sent in the clear) can:

  1. Strip strong options from the ClientHello before it reaches the server, making it look like the client only supports old, weak versions/ciphers.
  2. The server, seeing only weak options offered, negotiates the weakest thing on the list.
  3. Both sides believe they did a normal negotiation — neither realizes options were removed in transit.

💡 This only works if the client is still willing to accept old, weak protocol versions at all. Modern TLS clients disabling anything below TLS 1.2 (see 09-06: TLS Best Practices & HTTPS) removes the weak options an attacker could downgrade to in the first place.

The fix: signaling downgrade attempts

Modern TLS includes mechanisms like TLS_FALLBACK_SCSV, a special value a client includes when it's retrying with a lower version (e.g., because a previous attempt failed). If a server sees this value but is capable of a higher version than what's being offered, it knows a downgrade may be in progress and aborts the connection instead of proceeding.

🕰️ Historical Attacks (Conceptual Overview)

These attacks are largely irrelevant against a fully patched, modern TLS 1.2/1.3 setup — but understanding what made them possible explains why certain features were removed from later TLS versions.

POODLE (2014)

Padding Oracle On Downgraded Legacy Encryption, targeted SSL 3.0 specifically.

  • SSL 3.0's CBC-mode padding (see 07-03: AES & Block Cipher Modes for CBC mode) had a subtle flaw: the padding bytes at the end of a block weren't fully protected by the integrity check, so a server's specific way of rejecting bad padding could leak information back to an attacker.
  • An attacker who could get a victim's browser to retry the same request repeatedly (e.g., via malicious JavaScript) and who could also intercept traffic (a MITM position) could exploit these padding responses to decrypt small amounts of data, one byte at a time, across many requests.
  • Why it mattered beyond SSL 3.0 itself: because some servers/clients would downgrade to SSL 3.0 if a newer handshake failed, an attacker could force a downgrade (see above) specifically to create the conditions POODLE needed — this is why downgrade protection and simply removing SSL 3.0 support entirely became standard practice.

BEAST (2011)

Browser Exploit Against SSL/TLS, targeted a weakness in how TLS 1.0's CBC mode chose initialization vectors (IVs).

  • CBC mode (see 07-03: AES & Block Cipher Modes) needs an unpredictable IV for each block to stay secure. TLS 1.0's implementation used a predictable IV derived from the end of the previous record, rather than a fresh random one.
  • Combined with a way to get a victim's browser to send chosen, attacker-influenced plaintext repeatedly (again, malicious JavaScript in the browser), an attacker could gradually infer encrypted session-cookie-like data through careful, repeated guessing.
  • The fix: TLS 1.1 and later randomize the IV properly per record, closing the predictability gap that BEAST relied on.

💡 Notice the pattern in both attacks: (1) a subtle flaw in an older cryptographic mode/version, (2) an on-path or MITM position to observe traffic and manipulate retries, and (3) a way to make the victim's client repeatedly send attacker-chosen or predictable data. Modern TLS versions close the underlying crypto flaws; disabling old versions entirely closes the door regardless.

Not every TLS attack targets the cryptography — some target the trust model instead, tying back to 03-05: MITM Attacks & Defenses:

  • Rogue/mis-issued certificates — if an attacker can somehow get a CA to issue a certificate for a domain they don't legitimately control (through a compromised CA, a social-engineered validation process, or a compromised domain-validation check), they can present a "valid," properly-chained certificate for a site they don't own, and browsers won't complain at all.
  • Compromised or malicious root CA — if an attacker can get their own root certificate installed as trusted on a victim's device (e.g., through malware, or a corporate-managed device with an intercepting proxy's root CA installed), they can mint certificates for any domain that the victim's browser will fully trust — since trust ultimately rests on "is this root CA in my trusted list," not on any property of the traffic itself.
  • ARP spoofing / rogue Wi-Fi + a stripped connection — an attacker in a MITM position (see 03-04: ARP Spoofing Attacks) can't decrypt properly-validated TLS traffic, but they can try to prevent TLS from being used at all in the first place (e.g., intercepting the initial plaintext HTTP request before a redirect to HTTPS happens) — this is why HSTS exists.

Why Certificate Pinning Helps

Certificate pinning hardcodes (in an app or a browser policy) which specific certificate(s) or public key(s) are expected for a given domain, rather than trusting any certificate that happens to chain to any trusted root.

  • Even if an attacker manages to get a mis-issued or rogue certificate that would otherwise pass normal chain validation, pinning rejects it because it doesn't match the specific pinned key/certificate the app expects.
  • The tradeoff: pinning is inflexible — if the legitimate certificate needs to change (renewal, CA switch), pinned clients need an update too, or they'll break. This is why pinning is mostly used for high-value targets (mobile banking apps, certain browser-vendor-critical domains) rather than universally.

📌 Key Takeaways

  • Downgrade attacks strip strong options from the handshake so both sides settle for a weaker, breakable configuration; TLS_FALLBACK_SCSV-style signaling and simply refusing old versions are the fix.
  • POODLE exploited a padding-oracle flaw in SSL 3.0's CBC mode, often reached via a forced downgrade.
  • BEAST exploited predictable CBC-mode IVs in TLS 1.0, fixed by proper random IV generation in later versions.
  • Both historical attacks needed a MITM/on-path position plus a way to make the victim repeatedly send predictable or chosen data — not just "broken math."
  • Certificate-based MITM doesn't need to break crypto at all — mis-issued certificates or a rogue trusted root CA can make a fraudulent site look completely legitimate.
  • Certificate pinning defends against rogue/mis-issued certificates by hardcoding the expected certificate/key, at the cost of update flexibility.
  • The practical upshot for defenders is in 09-06: TLS Best Practices & HTTPS: disable old versions, use modern cipher suites, and don't rely on trust assumptions alone where pinning is warranted.