SSL termination is the point in a network path where an encrypted TLS connection ends. Whatever happens after that point, plaintext, re-encryption, or nothing, is a separate decision.

"SSL termination" gets used two ways. Sometimes it means the same thing as SSL offloading: a load balancer ends the encrypted connection and forwards plaintext. Other times it just describes the event itself, the moment a TLS session closes, regardless of what's on the other side. Both uses are correct. The difference is scope.

Termination Marks Where a TLS Session Ends, Not What Happens After

Every TLS connection has two ends. When traffic reaches a device that holds the private key and completes the handshake, that connection terminates there. That device now has the decrypted data. What it does next depends on the architecture:

  • Forward it as plaintext to a backend on a trusted network (this is SSL offloading).
  • Re-encrypt it in a new TLS session before sending it onward (this is SSL bridging).
  • Do nothing further with it because the terminating device is the final destination.

Termination is the event. Offloading and bridging are two different choices about what comes after it.

The Terminating Device Holds the Certificate and the Risk

Whatever terminates the connection needs the private key for that certificate. This is why termination points are centralized: a load balancer, a reverse proxy, a CDN edge node. Centralizing the key also centralizes the responsibility. If that device is compromised, every connection it has ever terminated was visible to it in plaintext for at least a moment.

That's the tradeoff termination always carries. It enables inspection, routing logic, and header-based decisions that require reading the request. It also means something other than the original client and the original server saw the unencrypted data.

Termination Is the Wrong Choice When Nothing but the Two Endpoints Should See the Data

Regulated data flows, payment card numbers, health records, anything under a contractual encryption-in-transit requirement, are the cases where termination at an intermediary defeats the point. If the requirement is that only the client and the final server can ever see the plaintext, terminating anywhere in between breaks that guarantee, even briefly. That's what SSL passthrough exists to solve.

The distinction matters for proxies too. QuotaGuard Static terminates SSL on its inbound side: it holds the certificate, completes the handshake, and forwards the request to your app behind it. That's separate from outbound traffic, where Static and Shield both route HTTPS through a blind CONNECT tunnel without terminating or decrypting it at any point. See SSL Termination vs. SSL Passthrough vs. SSL Offloading for how termination applies differently on the inbound and outbound side of a proxy.

QuotaGuard Static IP Blog

Practical notes on routing cloud and AI traffic through Static IPs.

Reliability Engineered for the Modern Cloud

For over a decade, QuotaGuard has provided reliable, high-performance static IP and proxy solutions for cloud environments like Heroku, Kubernetes, and AWS.

Get the fixed identity and security your application needs today.