Encryption in Transit & mTLS

TLS 1.3 is the baseline

Encryption in transit protects data on every network hop against eavesdropping (confidentiality) and silent modification (integrity). The baseline is TLS 1.3. It matters because it dropped the insecure cruft that plagued TLS 1.2: no RSA key exchange, no static Diffie-Hellman, no CBC-mode ciphers, no renegotiation. Every 1.3 handshake uses ephemeral (Elliptic-Curve) Diffie-Hellman, which gives forward secrecy: even if an attacker records ciphertext today and steals your server private key next year, past sessions stay unreadable because the session keys were ephemeral and thrown away. The 1.3 handshake is also one round trip instead of two, which cuts connection latency noticeably at p99.

On top of the protocol you need cert hygiene. Serve a modern cipher suite only (AES-GCM or ChaCha20-Poly1305, both authenticated), send HSTS so browsers refuse to downgrade to plaintext HTTP, and automate issuance and rotation with ACME (Let's Encrypt or an internal ACME CA). Manual cert renewal is how you get a 3 a.m. outage when a wildcard expires. Short lifetimes (90 days publicly, hours internally) shrink the damage window of a leaked key.

mTLS gives every workload an identity

For service-to-service calls, ordinary TLS only proves the server's identity to the client. Mutual TLS (mTLS) makes both sides present certificates, so each workload cryptographically proves who it is. That cert becomes a portable workload identity: instead of "requests from inside the VPC are trusted," you get "this call came from the payments service, signed by our CA, cert not expired." A service mesh (Istio, Linkerd) or a sidecar (Envoy) typically issues short-lived certs (often 24 hours or less via SPIFFE/SVID) and rotates them automatically, so revocation is rarely needed because certs expire faster than you would notice a compromise.

  north-south (edge)              east-west (internal)
  client --TLS1.3--> [LB/CDN]     svcA <==mTLS==> svcB
     terminate here?                 both present certs,
        |                            both verify against CA,
   re-encrypt to origin             short-lived, auto-rotated

Termination vs re-encryption

Terminating TLS at the edge load balancer or CDN lets it inspect, route, and cache, but the hop from the LB to your origin is now in the clear unless you re-encrypt. For sensitive data you terminate at the edge and open a new TLS (or mTLS) connection to the backend, so plaintext never crosses an untrusted segment. Inside a mesh, every pod-to-pod hop is re-encrypted with mTLS.

Interview nuance: revocation is the hard part of PKI. OCSP and CRLs scale poorly and can fail open, so the industry answer is short-lived certificates (expire before revocation would matter) rather than relying on revocation lists. Certificate pinning stops a rogue CA but is operationally brittle: pin the wrong cert or forget to rotate the pin and you brick your own clients, which is why mobile teams pin to a CA or backup key, not a single leaf.

Recap: baseline on TLS 1.3 for forward secrecy and downgrade protection, automate cert issuance and rotation, and use mTLS with short-lived certs to give every service a verifiable identity so you never trust the network alone.