HSTS, Certificate Transparency, And ECH

We've built up TLS from the ground up, looked at TLS 1.3, dissected cipher suites, talked about Perfect Forward Secrecy and revocation. But TLS by itself still leaves three gaps:

• Downgrade attacks — nothing stops an attacker from making the first connection plain HTTP and serving a fake page;
• Hidden mis-issued certificates — nothing stops a compromised or malicious CA from secretly issuing a cert for your domain;
• SNI leakage — the domain you're connecting to is still visible to anyone watching the wire, even in TLS 1.3.

Each gap has a modern fix. This chapter covers all three.

Fix 1 — HSTS (HTTP Strict Transport Security)

The attack: Maria types example.com in her address bar. The browser, by default, tries http://example.com first. An attacker on her network intercepts that HTTP request, serves a fake login page, and harvests her password. The user never sees an HTTPS warning because they never got to HTTPS in the first place.

The fix: HSTS is a response header the server sends over HTTPS that tells the browser:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

This says: "For the next 2 years, only ever connect to me over HTTPS. Apply this to all subdomains. And I want to be on the preload list."

After Maria's first successful HTTPS visit, her browser refuses to ever speak HTTP to this domain for the next 2 years. The attacker can no longer intercept — the browser won't even send the initial HTTP request.

The HSTS Preload List — Even The First Visit

HSTS has one weakness: the very first visit to a site, before any HSTS header has been received, can still be downgraded. The fix is the HSTS preload list — a list of domains that browsers hardcode as "HTTPS-only" out of the box.

If you submit your domain to hstspreload.org and it meets the criteria (HSTS header with max-age ≥ 1 year, includeSubDomains, preload directive, fully HTTPS everywhere), it gets baked into Chrome, Firefox, Safari, and Edge in their next release. Even a brand-new browser visiting your site for the first time will refuse plain HTTP.

Most major sites are on the preload list — Google, GitHub, PayPal, Twitter, Cloudflare, every major bank. For high-traffic services it's worth doing. The downside: getting off the preload list takes months. Don't preload until you're sure every subdomain works over HTTPS.

Fix 2 — Certificate Transparency

The attack: in 2011, a CA called DigiNotar was hacked. Attackers used it to issue fake certificates for Google, used by Iranian authorities to surveil Gmail. The certificates were technically valid — they chained back to a trusted root. Nobody knew they existed until the attack was already underway. There was no way to detect mis-issuance.

The fix: Certificate Transparency (CT) requires every certificate issued by a publicly trusted CA to be published to a public, append-only, cryptographically verified log within hours of issuance.

How it works:

• The CA submits the certificate to one or more CT logs;
• The log returns a Signed Certificate Timestamp (SCT) — proof of inclusion;
• The CA embeds the SCT in the certificate or sends it alongside;
• Browsers refuse to trust certificates without sufficient SCTs (typically 2 from independent logs);
• Anyone can monitor the logs in real time.

Public log operators include Google's Argon and Xenon, Cloudflare's Nimbus, Let's Encrypt's Oak, and others. They mirror each other for redundancy.

The practical effect: if any CA — compromised, malicious, or just buggy — issues a certificate for yourbank.com, the cert appears in public logs within hours. Tools like crt.sh let anyone search every cert ever issued for any domain. Domain owners can subscribe to alerts.

CT has been mandatory for all browser-trusted certificates since 2018. It's the system that caught Symantec mis-issuing certs and is still the front line for spotting CA misconduct.

Fix 3 — Encrypted Client Hello (ECH)

The attack: even with TLS 1.3, the Server Name Indication (SNI) field in the ClientHello is plaintext. It tells the network which hostname you're connecting to so the server (often a CDN handling many domains on one IP) knows which certificate to serve. Anyone watching the wire — your ISP, your government, a coffee shop — can see:

• That you connected to 1.1.1.1;
• That the SNI says yourbank.com;
• Therefore, that you visited your bank.

The encryption hides what you said. The SNI reveals who you said it to.

The fix: Encrypted Client Hello (ECH), standardized as RFC 9460. The idea:

• The website publishes a public ECH key in a DNS record;
• The client retrieves the ECH key;
• The client builds the ClientHello as usual, including the real SNI, then encrypts the whole thing with the ECH key;
• The client sends a fake "outer" ClientHello with a generic SNI (e.g., ech-relay.cloudflare.com) and the encrypted ClientHello inside;
• The CDN decrypts it, sees the real target, and routes the connection internally.

The wire now reveals only "connection to a Cloudflare IP for some Cloudflare-fronted site." The actual domain is unreadable.

Deployment status in 2026:

• Cloudflare turned ECH on by default for millions of domains in September 2023;
• Firefox supports ECH since version 119 (2023);
• Chrome added ECH support but had it behind a flag for a while; it's broadly available in 2026;
• Safari supports ECH starting iOS/macOS 17.

ECH is still rolling out. Adoption requires both browser support and a CDN/server that implements it. But the trajectory is clear — within a couple of years, the plaintext SNI leak will be largely closed.