
Network & Transport Security
TLS 1.3 in detail, mutual TLS for service-to-service, certificate pinning, the death of perimeter security, and the practical shape of a Zero Trust architecture.
What you will learn
The internet was designed for resilience, not for trust. Every layer above IP — DNS, TCP, the first decade of HTTP — assumed that anyone who could see the bits was at worst a curious researcher. We now operate the same protocols against nation-state adversaries with line-rate hardware. Transport security is the bandage we have all wrapped around that mismatch, and Zero Trust is what's replacing the bandage.
TLS 1.3 — What's Really Happening
You saw the four-message sketch on Day 2. Now the engineering details.
Why That's a Big Deal
- 1-RTT — half the connection latency of TLS 1.2 (and 0-RTT resumption is possible, with replay caveats).
- Forward secrecy mandatory — every session uses an ephemeral ECDHE key. Compromising the cert later does not retroactively decrypt today's traffic.
- Five cipher suites, all AEAD:
TLS_AES_128_GCM_SHA256,TLS_AES_256_GCM_SHA384,TLS_CHACHA20_POLY1305_SHA256, plus two for legacy. No more downgrade-prone catalog. - Encrypted Extensions — hides ALPN and other negotiation from passive observers (SNI is still cleartext until ECH lands universally).
POST /transfer) — most servers restrict 0-RTT to GETs for exactly this reason.Certificates — What the Server Is Actually Sending
An X.509 certificate binds a public key to a name via the signature of a certificate authority. The browser trusts the public-key bag of trusted roots in its trust store; everything else chains to one of them.
# the leaf certificate Subject: CN=api.example.com SAN: DNS:api.example.com, DNS:*.api.example.com Issuer: CN=R3, O=Let's Encrypt Not Before: 2026-01-12 Not After: 2026-04-12 Public Key: ECDSA P-256 SCT: embedded (Certificate Transparency) OCSP: http://r3.o.lencr.org
Five things the client checks on every handshake:
- Name — the
Subject Alternative Namematches the host being connected to. (CN-only matching is dead — modern clients ignore CN.) - Validity period —
Not Before< now <Not After. - Chain — leaf → intermediate(s) → trusted root.
- Revocation — OCSP stapling preferred; CRLs fall back; some browsers use CRLite.
- Certificate Transparency — embedded SCTs prove the cert was published to public logs (defends against rogue/CA-misissued certs).
HSTS — The Critical Header
Even with TLS, the very first request to a site might be HTTP. HSTS tells the browser: for this domain, never speak HTTP again — for the next N seconds.
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Submitting your domain to the HSTS preload list means even the first request from a fresh browser is HTTPS-only.
mTLS — Mutual Authentication for Service-to-Service
In one-way TLS the server proves who it is; the client is anonymous (and authenticated above the protocol, e.g. by JWT). mTLS requires both ends to present a certificate. It is the workhorse of service mesh authentication.
Standards / tools to know:
- SPIFFE / SPIRE — workload identity standard (
spiffe://URIs in cert SAN). - Service mesh — Istio, Linkerd, Consul Connect issue and rotate certs sidecar-style.
- Cloud-native equivalents — AWS IAM Roles Anywhere, GCP Workload Identity Federation.
- Short-lived certs — measured in hours, not years. Rotation is the answer to revocation.
Certificate Pinning — Use With Care
Pinning means the client refuses any cert outside a predetermined set, ignoring even valid CA-issued certs. Once standard for high-assurance mobile apps; now usually overkill thanks to Certificate Transparency and revocation tooling. The pitfall: a botched rotation can brick every installed client.
Good fits: dedicated mobile/IoT apps you ship updates to. Bad fits: browsers (Chrome and Firefox have removed HPKP for exactly the brick risk).
Zero Trust — The End of Network Position
The classical model: trust the inside, distrust the outside, watch the perimeter. Zero Trust says: network position implies nothing. Every request must authenticate, every authorization must be explicit, every session must be observable.
- VPN = trusted
- Inside the firewall = trusted
- Lateral movement is easy
- One foothold ≈ full breach
- Identity-aware proxy on every endpoint
- mTLS / SPIFFE between services
- Per-request policy decision
- Continuous verification (device posture, MFA freshness, anomaly score)
Concretely, in 2025 Zero Trust shows up as:
- Identity-aware proxies at the edge (Cloudflare Access, Google IAP, Tailscale ACLs).
- Service mesh mTLS with policy engines (OPA, Cedar, AuthZed) deciding per-call.
- Conditional access — login allowed only from managed devices with current OS patch level.
- Privileged access management — short-lived JIT credentials for admin tasks.
Network Hardening Checklist
- TLS 1.2 or 1.3 only; no 1.0/1.1, no SSLv3. Disable weak suites (no RC4, 3DES, CBC-without-AEAD).
- HSTS preloaded for every public hostname.
- Certificate Transparency monitoring — alert on any cert issued for your domains you didn't request.
- Egress filtering — deny by default, allow specific destinations. Defeats data exfiltration.
- Network segmentation per workload class (PCI separate from analytics from prod-DB).
- DNS security: DNSSEC for authoritative; DoH/DoT for resolvers; no plaintext UDP/53 to the internet.
- Regular external attack-surface review (Shodan, Nuclei templates, your own).
Show answer
- One round trip — TLS 1.3 1-RTT
- Ephemeral keys — ECDHE → forward secrecy
- AEAD only — GCM, ChaCha20-Poly1305
- Identity everywhere — mTLS / SPIFFE between services
- RFC 8446 — TLS 1.3 specificationdatatracker.ietf.org
- NIST SP 800-207 — Zero Trust Architecturenist.gov
- NIST SP 800-52 Rev. 2 — TLS configuration guidelinesnist.gov
- RFC 6797 — HSTSdatatracker.ietf.org
- RFC 9162 — Certificate Transparency 2.0datatracker.ietf.org
- Mozilla Server-Side TLS Guidelines (Modern / Intermediate / Old configs)wiki.mozilla.org
- SPIFFE — workload identity standardspiffe.io
Finished reading?