SSL Termination

When a browser connects to https://example.com, it opens a TLS connection: a handshake to agree on encryption keys, then encrypted data flowing both ways. Someone has to hold the certificate and private key for example.com and do the math to decrypt that traffic. SSL termination means that someone is your load balancer or reverse proxy, not your application server.

The proxy sits at the edge of your network. The encrypted connection ends (terminates) there. The proxy decrypts the request, then forwards it to a backend server over plain HTTP, usually inside a private network the public cannot reach. The response goes back the same way: backend speaks plain HTTP to the proxy, the proxy re-encrypts it and sends it to the browser.

The name is a bit dated. We mostly use TLS now, not the older SSL protocol, but the term SSL termination stuck. You will also hear it called TLS termination or SSL offloading, which all mean the same thing.

You install the TLS certificate and private key on the proxy (Nginx, HAProxy, an AWS ALB, Cloudflare, and so on). When a client connects, the proxy runs the TLS handshake: it presents the certificate, negotiates a cipher, and derives session keys. This handshake involves expensive public-key operations, which is the part you are trying to move off your application servers.

Once the session is established, the proxy decrypts each request into plain HTTP bytes. Because it now sees the unencrypted request, it can read the Host header, the path, and cookies, which lets it route, load balance, cache, rate limit, and add headers like X-Forwarded-For and X-Forwarded-Proto. A pure TCP passthrough cannot do any of that because it never sees inside the encryption.

From the proxy to the backend, the traffic is plain HTTP by default. That is fine if the link is a trusted private network. If you also encrypt the proxy-to-backend hop, you have TLS re-encryption (sometimes called SSL bridging): the proxy terminates the client TLS, inspects the request, then opens a fresh TLS connection to the backend. Compliance regimes like PCI DSS often require this so traffic is never in plaintext on the wire, even internally.

Use SSL termination when you have many backend servers and want one place to manage certificates and renewals, when you want the proxy to inspect and route HTTP traffic, or when your application servers are spending too much CPU on TLS. Centralizing certificates is the biggest practical win: with tools like Let's Encrypt and automated renewal, you rotate one cert at the edge instead of deploying it to fifty machines.

The main downside is that traffic between the proxy and the backend is unencrypted unless you re-encrypt it. If an attacker is already inside your network, or if you run in a shared environment, that plaintext hop is a real risk. This is why end-to-end TLS or a service mesh with mutual TLS is preferred for sensitive systems.

The other thing to watch is that backends no longer see the original client connection directly. They see the proxy. You must trust and read forwarded headers (X-Forwarded-For for the real client IP, X-Forwarded-Proto to know the request was originally HTTPS) or you will log the load balancer IP for everyone and possibly build broken redirect loops. Modern TLS with hardware AES acceleration also makes the CPU savings smaller than they were a decade ago, so for many teams the routing and certificate-management benefits matter more than the offload.

Say you run a web app on three EC2 instances behind an AWS Application Load Balancer. You upload your certificate to AWS Certificate Manager and attach it to the ALB's HTTPS listener on port 443. Browsers connect to the ALB over HTTPS; the ALB terminates TLS, then forwards requests to your instances over plain HTTP on port 80 inside your VPC.

Your three instances never touch a certificate, never run a TLS handshake, and never need updating when the cert renews, ACM rotates it on the ALB automatically. Each instance reads the X-Forwarded-For header to log the real visitor IP and the X-Forwarded-Proto header to know the original request was secure, so it can force HTTPS redirects correctly.

If a security review later requires encryption all the way to the instance, you flip the ALB target group to HTTPS and put a certificate on each instance too. Now the ALB still terminates the client TLS, inspects and routes the request, then re-encrypts to the backend. Same termination pattern, with the internal hop locked down.