TLS Termination Boundary

A security questionnaire asks whether data is encrypted in transit. The team answers yes, because the load balancer serves TLS 1.3. The answer is true and describes one hop out of four.

Termination is a location, not a property. Client to edge is encrypted. Edge to application, application to database, application to cache: each is a separate decision somebody made, usually by default and usually without writing it down. Naming the termination point converts a vague reassurance into a reviewable fact, and the review normally finds the boundary sitting further out than anyone assumed.

The boundary matters because of what travels in headers. A request body is one customer's data. A session cookie or bearer token is that customer's whole session, replayable against every service that accepts it, for as long as it lives.

Why it matters

The compliance framing has encouraged the confusion. Standards have historically required strong cryptography for sensitive data over open public networks, which is exactly the hop a load balancer certificate covers, so an estate can be compliant and still run plaintext internally. That is defensible in some architectures and an accident in most.

The practical consequence is blast radius. With plaintext behind the boundary, code execution on one host exposes the traffic that host handles. Reading another host's traffic in a managed cloud network normally needs either that host or a traffic-mirroring permission, so the exposure is one machine's share of requests rather than the fleet. That number is large enough to matter and small enough that the fix need not be a mesh.

Implementation patterns

• Terminate at the edge and re-encrypt to the backend. One listener setting and a server certificate. The move most estates should make first, and it closes the wire with no new control plane.
• Pass-through to the workload, where the application holds the certificate. Strongest for the hop, and it removes the edge's ability to inspect, route on content or run a web application firewall.
• Mutual TLS through a mesh, which gives the wire plus a verified caller identity. The identity is the point; the encryption is a side effect available more cheaply.
• Separate boundaries for separate legs, written onto the architecture diagram hop by hop. Database and cache connections are their own decisions, and a cache protocol with no authentication over a plaintext wire is usually the weakest leg on that diagram.

Industry example

A communications API platform in Twilio's position would terminate TLS at edge points close to its callers, because the public leg is the long and hostile one and the latency saving is real: a handshake is one round trip under TLS 1.3, and one round trip across an ocean is 100 ms or more. The boundary then sits at the edge, so every internal leg becomes a separate decision, which is why platforms of that shape fund internal transport security as a second programme.

Failure scenarios

• Code execution on one host reading plaintext bodies and, worse, bearer tokens for the requests it handles.
• A sidecar bypass: traffic leaving the pod without passing the proxy, so the mesh's guarantees do not apply to that call and nothing reports it.
• Certificate expiry on an internal leg, which fails closed and takes the service down, which is the reason teams quietly turn internal TLS off.

Trade-offs

Re-encrypting to the backend costs a certificate lifecycle per backend and a small CPU increase, and gives up nothing else. Pass-through gives the strongest hop and gives up content routing and edge filtering. Mutual TLS everywhere costs a control plane, a certificate authority, a fraction of a millisecond to a few milliseconds per hop, and a new outage mode when rotation fails. The CPU cost is mostly handshakes, so it scales with connection churn and hop count rather than with bytes.

When not to use it

Pushing the boundary into every workload is not always right. For a small estate on a private network with no multi-tenant compute and a team that cannot operate a certificate authority, terminating at the edge and re-encrypting one hop is the proportionate answer, and a mesh bought for encryption alone costs more availability than it buys confidentiality. Mutual TLS earns its price when you need the caller's identity for an authorisation decision, when untrusted code runs on shared compute, or when an assessor must be shown the boundary.

Interview question

Q: "Walk me hop by hop from a mobile client to your database and tell me where ciphertext becomes plaintext at each step. Then tell me which single hop you would secure first with one engineer-week, and why not the others."

What a strong answer covers: four or five named hops rather than a single yes; tokens in headers as the high-value cargo; re-encryption from edge to backend as the cheap first move; the cache leg as the commonly forgotten one; and the condition that makes mutual TLS necessary, namely needing caller identity for authorisation.

Quick check

Quiz: The load balancer serves TLS 1.3 and forwards plain HTTP. What does an attacker on the application host gain that matters most? Answer: bearer tokens and session cookies in the clear, replayable against every service that accepts them.

Flashcard: What does TLS termination move? The point where ciphertext becomes plaintext, not the plaintext itself.