SSL Bridging vs. SSL Offloading: What Changes on the Backend Leg

Both bridging and offloading start the same way: the load balancer terminates the incoming TLS connection and can read the request in plaintext. Where they split is what happens on the next hop, the leg between the load balancer and the backend server.

Offloading Sends the Second Leg as Plaintext

SSL offloading assumes the network between the load balancer and the backend is trusted, usually because it's a private subnet inside the same VPC or data center. Once the load balancer decrypts the inbound request, it forwards it over plain HTTP. No second handshake, no second certificate, minimal added latency. The backend server does no TLS work at all.

Bridging Re-Encrypts the Same Traffic for the Second Leg

SSL bridging does everything offloading does, then adds a step: instead of forwarding plaintext, it opens a new TLS connection to the backend and re-encrypts the traffic before sending it. The backend server now needs its own certificate and does its own handshake, just like it would under a passthrough model. The difference from passthrough is that the load balancer already decrypted and can inspect the traffic in the middle; it just chooses to protect the second leg instead of leaving it plaintext.

This costs more than offloading. Two TLS handshakes instead of one, two sets of certificate management, more CPU on both the load balancer and the backend. What it buys is encryption on every hop of the path, combined with the ability to inspect and act on the traffic at the load balancer, something passthrough can't do at all.

Choose Bridging When the Internal Network Isn't Fully Trusted

Offloading is the right default when the backend network is genuinely private and the only cost of plaintext there is a theoretical risk. Bridging earns its overhead when that assumption doesn't hold: shared infrastructure, multi-tenant backend networks, compliance language that requires encryption on every network segment rather than just the public-facing one, or a security team that doesn't want to certify an internal segment as trusted just because it's internal.

A useful way to think about it: offloading optimizes for speed and simplicity by trusting the internal network. Bridging keeps the security posture of passthrough on the second leg while keeping the inspection capability of termination on the first.

QuotaGuard's outbound proxying doesn't use bridging on customer traffic; both Static and Shield carry outbound HTTPS through a blind CONNECT tunnel and never decrypt the payload to re-encrypt it, so there's no plaintext moment to protect in the first place. The bridging-vs-offloading choice mainly comes up when you're designing your own backend architecture behind a load balancer, not when routing outbound traffic through a proxy. See SSL Termination vs. SSL Passthrough vs. SSL Offloading for how QuotaGuard's model differs from a bridging setup.