The Engineering Codex/Application Security Engineering
DAY 5
07 / 09

Network & Transport Security

schedule6 minsignal_cellular_altIntermediate1,301 words
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

01TLS 1.3 — What's Really Happening
02Certificates — What the Server Is Actually Sending
03mTLS — Mutual Authentication for Service-to-Service
04Certificate Pinning — Use With Care
05Zero Trust — The End of Network Position
06Network Hardening Checklist

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.

Client Server ClientHello supported_versions, cipher_suites, key_share (X25519), SNI, ALPN ServerHello + EncryptedExtensions + Cert + CertVerify + Finished picks suite, sends key share, signs handshake transcript Finished verifies cert chain, derives session keys via HKDF Application Data 🔒 (AES-GCM / ChaCha20-Poly1305) What changed in 1.3 vs 1.2 1-RTT (was 2). Forward secrecy mandatory (ECDHE only). RSA key transport removed. Static-DH removed. Only 5 cipher suites. AEAD only. Encrypted Extensions hides server-provided params from passive observers.
TLS 1.3 — fewer round trips, no broken modes left, every connection has forward secrecy.

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).
⚠️
0-RTT, with care
0-RTT lets the client send application data on its first message using a previous session ticket. The trade-off: that early data is replayable. Never use 0-RTT for non-idempotent requests (no 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.

openssl s_client -showcerts
# 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:

  1. Name — the Subject Alternative Name matches the host being connected to. (CN-only matching is dead — modern clients ignore CN.)
  2. Validity periodNot Before < now < Not After.
  3. Chain — leaf → intermediate(s) → trusted root.
  4. Revocation — OCSP stapling preferred; CRLs fall back; some browsers use CRLite.
  5. 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.

HTTP
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.

Service A SPIFFE ID spiffe://acme/svc/checkout 🔐 Service B SPIFFE ID spiffe://acme/svc/payments 🔐 A presents cert B presents cert + verifies A Both sides have cryptographic identity. No bearer token to leak.
mTLS gives both sides cryptographic identity and short-lived certs (typical TTL: 1–24h). The basis of every modern service mesh.

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.

Castle & moat (legacy)
  • VPN = trusted
  • Inside the firewall = trusted
  • Lateral movement is easy
  • One foothold ≈ full breach
Zero Trust
  • 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).
Active recall
Your service mesh uses mTLS between every pod. A teammate argues that JWT-based authorization is now redundant. Are they right?
Show answer
No. mTLS proves workload identity — "this request came from the checkout service." It does not carry the original end-user identity. You still need a propagated user token (JWT, signed header) so downstream services can enforce per-user authorization. mTLS authenticates the caller; the token authorizes the action.
Flashcard
Why is forward secrecy more important now than it was ten years ago, and what protocol feature provides it?
Click to flip ↻
Answer
Adversaries (especially state actors) record encrypted traffic today and store it hoping for future cryptographic advances or key compromise. Forward secrecy means tomorrow's key leak does not retroactively decrypt today's traffic. In TLS 1.3 it is mandatory and provided by ECDHE — every session uses ephemeral key shares; the server's long-term key only signs the handshake.
Mnemonic — modern transport
"One round trip, ephemeral keys, AEAD only, identity everywhere."
  • One round trip — TLS 1.3 1-RTT
  • Ephemeral keys — ECDHE → forward secrecy
  • AEAD only — GCM, ChaCha20-Poly1305
  • Identity everywhere — mTLS / SPIFFE between services
🔑
Key takeaways
1) TLS 1.3 is the floor — fewer round trips, only safe modes left, forward secrecy mandatory. 2) Certificates bind keys to names; trust is in chains, transparency logs, and short lifetimes. 3) mTLS gives every workload a cryptographic identity; the basis of modern service-mesh AuthN. 4) Zero Trust replaces "trust the inside" with "verify every request" — a posture shift more than a product. 5) HSTS + CT monitoring + egress filtering are the cheap, high-leverage controls every team should already have.

Finished reading?