Downgrade, MITM, And SNI

Last chapter covered attacks that were patched out of TLS itself. This chapter is about attacks that are still alive in 2026 — what they look like, and what stops them.

Downgrade Attacks

The pattern: an attacker between the client and server modifies the handshake to force both sides to negotiate weaker crypto than they would have on their own. Classic technique:

• Drop or corrupt ClientHellos that advertise TLS 1.3;
• Make the client retry with a fallback ClientHello;
• The fallback advertises only weaker versions or weaker ciphers;
• Server accepts the weaker option, thinking that's the best the client supports.

This was how POODLE worked. The attacker downgraded TLS to SSL 3.0 and exploited it from there.

TLS 1.3 has built-in downgrade protection. The server's ServerHello.random field contains a specific magic value if it knew the client supported a higher version. A TLS 1.3-capable client checks this — if the magic value is present but the connection is on a lower version, the client knows something tampered with the handshake and aborts.

The catch: this only works when both sides support TLS 1.3. If your server allows TLS 1.0 or 1.1, those versions don't have this protection. Kill them.

Practical rule for 2026: disable TLS 1.0, TLS 1.1, and SSL 3.0 on every internet-facing server. Modern Nginx and Apache defaults already do this, but verify.

MITM — Man-in-the-Middle

A MITM attack has someone positioned between client and server, intercepting and potentially modifying traffic. There are two flavors:

Flavor 1 — Opportunistic MITM (attacker has no trusted certificate). Attacker presents a certificate they generated themselves. The browser walks the chain, finds the attacker's "CA" is not in the trust store, and shows a scary red warning. Users who click through it get owned. Browsers have made this UI increasingly hostile (Chrome's red error page, Firefox's full-screen block) precisely because so many users used to ignore it.

Flavor 2 — Authorized MITM (corporate networks). Many corporations install a custom root CA on every device they manage. Their network gateway then transparently re-encrypts all outgoing TLS traffic with certs signed by that corporate root. This is legitimate — it's how DLP, malware scanning, and policy enforcement work. But it means:

• The corporate gateway can read every byte of every employee's HTTPS traffic;
• If the corporate root CA's private key leaks, an attacker can do the same thing transparently;
• Some sites (banking, healthcare) detect and refuse to load through corporate proxies via certificate pinning or HPKP-style controls.

If you're a sysadmin, treat your corporate CA's private key the way you'd treat a nuclear launch code. If you're a user, assume your work laptop has zero TLS privacy on the corporate network. That's not paranoia — it's the design.

Defenses That Actually Work Against MITM

• HSTS preload — prevents downgrade to HTTP on the first connection;
• Certificate Transparency — catches mis-issued certs from rogue or compromised CAs within hours;
• Public Key Pinning (DANE/TLSA, plus narrow uses of HPKP) — declares "for this domain, only certs from this specific CA or with this specific key are valid." Few sites use this because misconfiguration locks legitimate users out;
• Cert monitoring services — tools like Cert Spotter, Facebook's CT Monitor, or crt.sh alerts that email you when a new cert is issued for your domain.

If you're a domain owner, set up CT monitoring. It costs nothing and catches a class of attacks nothing else will.

SNI Leakage And ECH

We covered SNI and ECH at the end of Section 2. Here's the recap from an attacker's perspective:

Even with full TLS 1.3, the Server Name Indication in the ClientHello is plaintext on the wire. Anyone watching the connection — ISP, transit provider, nation-state, coffee shop wifi — can see:

• That you connected to IP 104.16.x.x (a Cloudflare IP);
• That the SNI says bankofcountry.com;
• Therefore, that you visited your bank.

They can't read the conversation. But they know who you talked to.

ECH (Encrypted Client Hello, RFC 9460) fixes this by encrypting the entire ClientHello with a public key the site publishes in DNS. The wire now shows only a generic outer SNI (e.g., ech.cloudflare.com). 2026 status:

• Cloudflare has ECH on by default for millions of domains;
• Firefox, Chrome, and Safari all support ECH;
• Roughly 50%+ of TLS handshakes to major CDNs use ECH today, and growing fast.

If you operate a site behind a CDN that supports ECH, you basically get it for free. If you self-host, ECH support is still limited — Nginx ECH support arrived experimentally in 2025 but it requires custom builds.

What An Attacker Sees Today — Best Case

If your site uses all of:

• TLS 1.3 only (or 1.2+ with hard exclusions);
• A Mozilla Intermediate / Modern cipher list;
• HSTS preload;
• ECH via a major CDN;
• Strict transport monitoring (CT alerts, no mixed content).

…then an attacker on the wire sees only encrypted bytes between two IP addresses. They can't tell which site, which user, which page, or which API. They can guess based on traffic patterns and timing, but they don't know.

That's the security ceiling we have in 2026.