TLS Termination and Offload

TLS termination is the point on the path where HTTPS gets decrypted. Put it at the load balancer or reverse proxy and the backends receive plaintext HTTP — the edge does the certificate handling and the crypto, and your application servers never touch a private key. That centralizes certificates onto one tier and offloads the CPU cost of the TLS handshake from every backend onto the edge. The catch is unavoidable: traffic behind the termination point is cleartext unless you do something about it.

That "something" is the real subject here. There are three ways to handle TLS at the edge — terminate, re-encrypt, and pass-through — and they trade performance, inspection, and visibility against end-to-end encryption. Termination is fastest and most capable but leaves an internal plaintext hop. Pass-through preserves end-to-end secrecy but blinds the edge. Re-encryption sits between them, paying twice the crypto to get both inspection and an encrypted backend leg. The choice is deliberate, and the wrong default leaks plaintext where your threat model said it shouldn't.

Termination — Decrypt at the Edge

In plain termination the edge holds the certificate for www.example.com, completes the TLS handshake with the client, decrypts the request, and forwards it to the backend over plaintext HTTP. This is the most common setup because it unlocks everything L7 needs — path routing, header rewriting, caching, WAF inspection — all of which require reading the request. It also means one place to install and renew certificates instead of a key on every backend.

The exposure is the internal hop. From the edge to the backend the traffic is cleartext, so anyone who can sniff that network segment reads it. On a trusted, isolated backend network that may be an acceptable tradeoff. In a zero-trust environment — where you assume the internal network is hostile — leaving that hop plaintext is exactly the gap an attacker pivots through, and you need re-encryption instead.

# nginx: terminate TLS at the edge, plaintext to the backend
server {
    listen 443 ssl;
    ssl_certificate     /etc/ssl/example.crt;
    ssl_certificate_key /etc/ssl/example.key;
    location / {
        proxy_pass http://10.0.0.11:8080;   # cleartext hop
    }
}

Re-Encryption — TLS Bridging

Re-encryption (also called TLS bridging) decrypts at the edge, inspects and routes the request, then opens a new TLS connection to the backend and re-encrypts. You get the best of both: the edge can read the request to do L7 routing and inspection, and the hop to the backend is encrypted so no internal segment carries plaintext. This is the standard pattern in zero-trust and regulated environments where every hop must be encrypted but the edge still needs to route on content.

The cost is two TLS handshakes and two rounds of crypto per request — once with the client, once with the backend — roughly doubling the edge's TLS CPU. The backend leg often uses mTLS so the edge and backend authenticate each other, not just encrypt. You pay the performance to close the plaintext gap, which is the right trade whenever the internal network is part of your threat model.

Pass-Through — End-to-End TLS

In pass-through (TLS passthrough) the edge never decrypts. It forwards the encrypted TCP stream to the backend, and the backend terminates TLS itself — the client's TLS session runs end to end to the actual server. The edge sees only ciphertext, so it cannot route on path or headers, cannot cache, and cannot inspect; it can balance only on the connection, at L4. What you get in return is true end-to-end encryption where not even your own edge holds the plaintext.

Choose pass-through when the requirement is that no middle box ever sees the content — strict compliance, client-certificate authentication that must reach the backend, or a service you simply do not want your edge able to read. The constraint is the L7 functionality you give up: if you also needed path-based routing, you cannot have it on encrypted bytes, and you must fall back to SNI for any routing at all.

SNI Routing — Choosing Before Decryption

Server Name Indication is the one piece of the TLS handshake sent in cleartext: the ClientHello carries the hostname the client wants, www.example.com, before any encryption begins. That single field is what lets one IP serve hundreds of HTTPS sites — the edge reads the SNI, picks the matching certificate, and completes the handshake for the right host. Without SNI, one IP could present only one certificate.

SNI is also what makes routing possible in pass-through mode. Because the hostname is visible before decryption, a pass-through balancer can read the SNI and send api.example.com to one backend pool and app.example.com to another — all without ever decrypting the payload. That is the only routing dimension you get without termination: by host, never by path, because the path lives inside the encrypted body.

# HAProxy: route by SNI in pass-through, no decryption
frontend tls_in
    bind *:443
    mode tcp
    tcp-request inspect-delay 5s
    tcp-request content accept if { req_ssl_hello_type 1 }
    use_backend api_pool if { req_ssl_sni -i api.example.com }
    default_backend app_pool