SSL/TLS Termination

SSL/TLS termination is the practice of decrypting incoming encrypted HTTPS traffic at a load balancer, reverse proxy, or dedicated appliance at the edge of a network, then forwarding the now-unencrypted traffic to backend application servers over an internal network, rather than having every individual backend server handle TLS decryption itself.

Why It’s Done

TLS encryption and decryption is computationally expensive relative to serving a simple HTTP request, and performing that cryptographic work on every single backend server — especially in an architecture with many backend instances behind a load balancer — duplicates that computational cost across every instance. Terminating TLS once, at a single point (a load balancer or dedicated proxy), and then distributing already-decrypted traffic to backend servers over a trusted internal network shifts that cryptographic overhead to one purpose-built point in the architecture, freeing backend application servers to spend their compute resources on actual application logic instead.

The Security Tradeoff

TLS termination requires trusting that the internal network between the terminating proxy and the backend servers is itself secure, since traffic travels unencrypted across that internal segment. In environments where this internal trust boundary is a meaningful concern — regulated industries, zero-trust network architectures, or multi-tenant environments where different customers’ traffic might share the same physical network — a variant called “TLS re-encryption” (or “TLS bridging”) is used instead, where the proxy decrypts incoming traffic, inspects or routes it as needed, then re-encrypts it with a separate TLS connection to the backend, preserving encryption end-to-end while still allowing the proxy to make routing decisions based on the traffic’s content.

Where It’s Implemented

TLS termination is a standard, built-in capability of load balancers like AWS’s Application Load Balancer and reverse proxies like NGINX and HAProxy, and it’s the default architecture for most web applications, since the internal network segment between a load balancer and its backend servers is typically already isolated within a private subnet with its own access controls, making full end-to-end encryption unnecessary for the majority of use cases.

Where Termination Happens in Modern Architectures

In containerized and serverless architectures, TLS termination responsibilities have shifted somewhat: a service mesh’s sidecar proxies can handle TLS termination and re-encryption for service-to-service traffic automatically, while a cloud load balancer or CDN typically still handles termination for external, internet-facing traffic. This layered approach means a single request in a modern architecture might have TLS terminated and re-established multiple times as it passes from the public internet through a CDN, into a load balancer, and finally to a specific backend service — each termination point representing a deliberate tradeoff between processing efficiency and maintaining encryption across each network segment the request traverses.