TLS Termination & Anycast Edge

Overview

Without an edge, the client's TLS handshake crosses the WAN: 1–2 round trips times 80–200 ms. That budget is TTFB before HTML even starts. A CDN POP terminates TLS a few milliseconds away, speaks HTTP/2 or HTTP/3 with multiplexing, and (on a HIT) never touches origin. Origin connections are a second, long-lived TLS session from shield to origin — hop encryption, not end-to-end privacy from the CDN.

Anycast advertises the same VIP from many POPs. BGP delivers the client to a topologically close POP. Geo-DNS answers different IPs from different resolvers. Most CDNs use both (Anycast for the data plane, DNS for service discovery or mixed steering).

Why edge TLS wins TTFB

0-RTT (TLS 1.3 early data) is a replay hazard for non-idempotent POST. CDNs enable it carefully; do not blindly turn it on for origin POSTs.

WAF, bot scoring, and HTTP/2 push-or-not all require plaintext at the POP. That is the product. If a threat model forbids the vendor seeing bytes, you do not put that traffic on a shared CDN — or you use a private offering with contractual isolation, not "HTTPS to origin" as a privacy story.

1. 1

   client → origin WAN RTT per handshake

   Origin-only TLS

   Every new connection pays origin RTT. No POP cache, no HTTP/3 at the edge, no Anycast failover of the VIP. TTFB is dominated by distance.

2. 2

   Winner for public sites: edge TLS + Anycast + warm origin TLS

   Client handshake is local. POP multiplexes HTTP/2 or HTTP/3. Shield keeps a warm TLS pool to origin. Cold miss pays an extra hop; HIT does not.

3. ?

   When origin mTLS / private link is still required

   If someone discovers the origin IP they must not pull it as an open website. mTLS, allow-listed CDN egress, or a private interconnect. Cleartext-in-VPC is not a substitute.

Anycast vs geo-DNS

Anycast flap. Severe routing changes can move the next packet to another POP. TCP often RSTs; the client reconnects. QUIC (RFC 9114 HTTP/3) is more sensitive: connection IDs and path validation assume a stable 4-tuple more than TCP's happy reconnect. CDNs engineer anycast-aware QUIC (connection ID routing, careful withdraw). Do not say "Anycast never moves."

Geo-DNS trap. The user is in Paris; their DNS resolver is a US 8.8.8.8 PoP; you steer them to Virginia. Anycast would have taken the TCP SYN to CDG. Complementary: Anycast the CDN VIP; use DNS for which VIP product (IPv4 vs IPv6, dual-stack, preview) and for origin failover when you are not on Anycast.

flowchart TB
  u["Step1 User"]
  d["Step2 DNS"]
  p["Step3 Anycast POP"]
  o["Step4 Origin"]
  u -->|Resolve cdn host| d
  d -->|Same VIP| u
  u -->|TCP or QUIC plus| p
  p -->|Encrypted| u
  p -->|Step6 TLS to| o
  o -->|Response| p

TLS offload vs end-to-end

Offload / termination at the edge: client ↔ POP is TLS. POP sees HTTP. POP ↔ origin should be TLS again (often with a different cert). This is two hops of encryption. The CDN is a trusted reverse proxy.

True end-to-end TLS (client encrypts to origin keys the CDN cannot decrypt) fights the point of a inspecting CDN. Tunneling CONNECT-style is not how HTML CDNs work.

Origin policy: never fall back to cleartext "because VPC." VPC is not encryption; it is a routing domain. Prefer private link or mTLS. Pin CA / ciphers if you must. Rotate origin certs with the same ACME automation you use at the edge.

When edge termination is the wrong product. If the threat model is "nobody but origin may see plaintext" (some healthcare, some payments, mutual-TLS APIs to partners), a inspecting CDN cannot sit in the middle. Options: skip the CDN for that hostname, use a tunnel that does not terminate HTTP, or a private/enterprise POP with contractual isolation — still not end-to-end to the browser. Public HTML sites almost always pick offload because WAF and cache require bytes.

Warm shield → origin TLS is why a cold miss is not 300 ms of handshake: the POP already has a session. That reuse is a latency side effect of hierarchy; the primary reason for a shield remains origin QPS.

Resolver in Virginia, user in Paris: geo-DNS may pin IAD until TTL dies. Anycast would have taken the SYN to CDG. Use Anycast for the VIP users hit; use DNS for product selection and for origins that are not Anycast.

HTTP/2 vs HTTP/3

At the POP, multiplexing is why one client connection fetches HTML + 40 assets without 40 handshakes. When sizing origin, remember the shield already coalesces — HTTP/2 to origin is connection reuse, not 40 WAN handshakes per page. See request collapsing for the miss storm HTTP/2 does not fix.

HOL, loss, and Anycast. On a 2% lossy mobile path, HTTP/2 over TCP stalls all streams on one retransmit. HTTP/3 recovers per-stream, which is why CDNs push it for last-mile. The cost is UDP 443 and Anycast: if BGP shifts the 4-tuple to another POP, QUIC must path-validate; a naive anycast withdraw looks like packet loss plus a new path. TCP usually RST + reconnect, which browsers already handle. Staff answer: enable HTTP/3 with HTTP/2 fallback; treat Anycast flap as a real QUIC bug class, not theoretical.

Session resumption. After the first POP handshake, session tickets (or TLS 1.3 PSKs) make the next navigation 0-RTT/1-RTT. Ticket keys are as sensitive as cert keys for that ticket lifetime. Rotate on a schedule; do not copy a static ticket key into a git repo so every POP "matches." 0-RTT early data is replayable — allow it for safe GET of cacheable HTML, not for checkout POST.

Certificates, tickets, stapling, keys

• ACME (Let's Encrypt) automates issuance. Monitor expiry; a missed renew is a site-wide outage the CDN will faithfully serve as TLS errors.
• SAN vs wildcard: exact names in SANs are tighter; wildcards are operationally easier and broader-blast on leak. Certificate Transparency logs both — watch CT for surprise issuances.
• Session tickets: the edge issues tickets so resumption skips a full handshake. Ticket keys must rotate; a stolen ticket key lets an attacker decrypt resumed sessions from that era.
• OCSP stapling: the POP staples OCSP so clients do not call the CA (privacy + extra RTT). If you disable stapling, mobile clients pay CA RTT or fail hard in some modes.
• Key custody: managed certs keep private keys in the vendor HSM/POP fleet. Uploading your own key to "every POP" expands the disclosure radius. Least POPs, HSM, or bring-your-own-key offerings when compliance cares.
• Policy: TLS 1.3 preferred; TLS 1.2 floor; disable 1.0/1.1. Client auth (mTLS from browsers) is rare at the CDN; that usually lives at the API gateway. mTLS from CDN to origin is the common staff ask.

SANs in practice. shop.cdn and www.shop.cdn and static.shop.cdn are three names. One cert can list them all in SANs, or *.shop.cdn covers the last two and not the apex. Apex + wildcard usually means two certs or a SAN that includes the apex. ACME HTTP-01 needs port 80 at the answering POP; DNS-01 is how you automate wildcards. CT monitoring is how you notice a cert you did not request.

Failover and health checks. Anycast withdraw is only as good as the health signal. If a POP is blackholing HTTP but still announcing BGP, users stick to a dead edge. Probe the data path (TLS + HTTP), not only the route. Combine with stale-if-error so other POPs can keep serving.

Playground: Anycast picker vs geo-DNS vs handshake budget

No sockets. POPs have a BGP distance and a geographic latitude. Geo-DNS uses resolver latitude, which can disagree with the user.

Press Run. Snippets must be self-contained — no network, files, or native modules.

Interview Q&A

Pitfalls

Go Deeper

• Cloudflare — Anycast network
• RFC 9114 — HTTP/3
• Let's Encrypt — ACME
• CloudFront — Using HTTPS
• Talk — Anycast networking explained

Sibling pages: CDN hierarchy · Cache keys · SWR / stale-if-error · Purge and generation tokens · Request collapsing