What is TLS offloading and when is it safe to use?

TLS offloading, also called TLS termination, means a load balancer, proxy or gateway decrypts incoming HTTPS so back end servers receive plain HTTP. It saves CPU and centralizes certificates, but it is safe only when the network behind the device is trusted and protected, or when traffic is encrypted again.

What actually happens to the traffic?

The client opens a TLS session with the offloading device, which holds the certificate and private key. The device decrypts the request, can inspect or route it, and forwards it to a back end. In the common simple setup that second hop is unencrypted. The response travels back the same way and is encrypted again for the client.

Two things follow. The device becomes a high value target, because it holds keys and sees every request in plain text. And the unencrypted segment becomes part of your trust boundary.

Why do teams do it?

• Central certificate management. One place to install and renew certificates instead of every server.
• Less CPU on back ends. Handshakes and bulk encryption move to a device sized for it.
• Inspection and routing. Web application firewalls, caches and routing rules can only act on content they can read. NIST SP 800-215 lists TLS decryption and inspection of packet payload as a capability of next-generation firewalls.

What are the risks?

Cleartext on the internal hop. Anyone who can observe that segment can read cookies, tokens and form data. In a shared cloud network or a flat internal network this is a real exposure.

Key concentration. A compromise of the offloading device exposes private keys and traffic for every service behind it.

Lost identity. If the back end sees only the proxy, it loses the client's certificate details unless the proxy forwards them in a trusted way. Mutual TLS from clients can be terminated at the proxy and then not enforced downstream.

Configuration drift. Weak protocol versions or cipher suites enabled at the device apply to everyone. RFC 9325 gives current recommendations for deploying TLS, and NIST SP 800-52 Rev. 2 requires TLS 1.2 with approved cipher suites for government servers, and support for TLS 1.3. Check your device against both.

What are the alternatives?

Re-encryption. The device decrypts to inspect, then opens a new TLS session to the back end. You pay the CPU cost twice but keep encryption on every hop.

Passthrough. The device forwards encrypted traffic without decrypting it. Back ends hold certificates and do the work, and you lose inspection at the device.

End-to-end with service mesh. Workloads authenticate each other with mutual TLS inside the cluster, and the edge terminates only the public side.

A constructed example

A retail site terminates TLS at a load balancer in a shared virtual network and forwards plain HTTP to six web servers. A misconfigured monitoring tool on another team's VM in the same network captures traffic and logs session cookies. Nothing broke at the edge, yet sessions were exposed. Moving to re-encryption, with the back ends holding internal certificates, closed the exposure at a small CPU cost.

How to check or apply this

1. Draw each path from client to application and mark where decryption happens.
2. Mark every segment after a decryption point as encrypted or plain.
3. Re-encrypt any segment crossing a shared or untrusted network.
4. Restrict who can log in to the offloading device and where keys are stored.
5. Disable obsolete protocol versions and weak ciphers at the device.
6. Forward client identity to back ends in a defined, authenticated header or protocol.
7. Review the setup when a new tool is added to the network.

Quick check

Sources

• RFC 9325, Recommendations for Secure Use of TLS and DTLS
• NIST SP 800-52 Rev. 2, Guidelines for TLS Implementations
• NIST SP 800-215, Guide to a Secure Enterprise Network

Last reviewed: 18 October 2026.