SSL Offloading: How It Works, the Security Tradeoffs, and When to Use Each Mode

SSL offloading is commonly presented as a performance optimization: move the CPU-intensive TLS handshake and encryption from backend servers to a dedicated device, free up application server resources, centralize certificate management. All of that is accurate. What the performance-first framing obscures is the security decision embedded in the choice.

When TLS terminates at a load balancer and traffic continues to backend servers as plaintext HTTP, the security model fundamentally changes. End-to-end encryption from client to application server no longer exists. Instead, the trust model becomes: the internal network path from load balancer to backend servers is trusted and secure. Whether that assumption is justified depends on the architecture. In a flat network with inadequate east-west traffic controls, an attacker who achieves lateral movement inside the perimeter can read every request flowing from the load balancer to the backends, including authentication tokens, session cookies, and sensitive application data.

This article covers what SSL offloading is and how it works, the three distinct operational modes and their security properties, the internal network trust question that determines whether offloading is appropriate, the controls that mitigate the exposure, and compliance considerations.

What SSL Offloading Is

SSL offloading (also called TLS termination or SSL termination) is the process of handling the TLS handshake and encryption operations at a dedicated network device rather than at the application server. The dedicated device can be a load balancer, a reverse proxy, an Application Delivery Controller (ADC), or a cloud-native service like AWS Application Load Balancer, Azure Application Gateway, or Cloudflare.

Every HTTPS connection requires a TLS handshake: asymmetric cryptography operations to negotiate keys, certificate validation, and session key derivation. Asymmetric cryptography is significantly more CPU-intensive than symmetric encryption. Under high traffic, the handshake overhead per connection accumulates and consumes meaningful server CPU. SSL offloading moves this work to a device purpose-built or specifically provisioned for it, allowing application servers to focus CPU cycles on application logic rather than cryptographic operations.

The operational benefit extends beyond CPU. A single SSL offloading device can manage one SSL certificate rather than requiring the same certificate to be installed, renewed, and managed on every backend server in the pool. Certificate rotation, renewal automation, and cipher suite policy become single-device operations.

The term SSL offloading is technically a misnomer. SSL (Secure Sockets Layer) was deprecated in 2015. The current protocols are TLS 1.2 and TLS 1.3. TLS termination is the technically correct term. SSL offloading persists in vendor documentation, product names, and industry usage because SSL remains the familiar term in these contexts. Both terms refer to the same operation.

The Three SSL Offloading Modes and Their Security Properties

Three distinct connection patterns exist for handling TLS between clients, the termination point, and backend servers. Understanding all three, and particularly their security properties, is prerequisite to making an informed architecture decision.

Mode 1: TLS Termination (Offloading)

The load balancer or reverse proxy terminates the TLS connection from the client. Decrypted plaintext traffic is forwarded to backend servers over HTTP on the internal network. The backend servers never handle TLS.

Security property: the internal network path from load balancer to backends carries plaintext. An attacker with network access to this path can read all traffic. The security of the architecture depends entirely on the controls protecting this internal path: network segmentation, host-based firewalls, monitoring for unexpected east-west traffic, and access controls preventing lateral movement into the load balancer-to-backend segment.

The forward pass of the original client IP requires a header. When TLS terminates at the load balancer, the backend server sees the load balancer’s IP as the source address, not the original client’s. The load balancer adds an X-Forwarded-For header containing the original IP. Applications that rely on source IP for rate limiting, geolocation, or audit logging must be configured to trust and use this header from the load balancer.

Mode 2: TLS Bridging (SSL Re-encryption)

The load balancer terminates the inbound TLS connection from the client, inspects the decrypted traffic, then establishes a new TLS connection to the backend server and re-encrypts the traffic before forwarding it. Two separate TLS sessions exist: client to load balancer, and load balancer to backend.

Security property: the internal network path is encrypted. An attacker with network access to the load balancer-to-backend segment cannot read the content of the traffic. The load balancer holds the private key for the client-facing certificate and also manages the certificate used for the backend connection (which can be a private CA certificate if the backends are internal servers).

TLS bridging is more CPU-intensive than pure termination because the load balancer must perform two TLS handshakes per client connection and maintain two encrypted sessions. The performance overhead is meaningful under high traffic. However, it preserves end-to-end confidentiality and is the appropriate mode when the internal network is not trusted or when compliance requirements mandate encryption of data in transit regardless of network location.

TLS bridging is the architecture used by Cloudflare, AWS ALB with HTTPS target groups, and most enterprise load balancers when configured for backend TLS. The Cloudflare SSL Inspection article in this series covers the same pattern from the inspection perspective. From the SSL offloading perspective, bridging is the security-preserving mode that eliminates the internal plaintext exposure while retaining the load balancer’s ability to inspect and route traffic.

Mode 3: TLS Passthrough

The load balancer does not decrypt the traffic at all. It forwards encrypted packets to backend servers without terminating the TLS session. The TLS connection is end-to-end between the client and the backend server. The backend server handles TLS itself.

Security property: the load balancer never sees plaintext. The backend server holds the private key and certificate. Traffic is encrypted from client to backend with no decryption point in between.

The operational limitation is inspection capability. A load balancer performing TLS passthrough cannot read HTTP headers, cookies, or request paths. Routing decisions must be based on network-layer information (IP address, TCP port) or on the SNI (Server Name Indication) value in the TLS ClientHello, which is visible in plaintext before the TLS handshake completes. Layer 7 routing, session persistence based on cookie values, web application firewall inspection, and HTTP header manipulation are all unavailable in passthrough mode.

The Central Security Question: Can You Trust the Internal Network?

Whether TLS termination without re-encryption is an acceptable security posture depends on a question that many teams answer by assumption rather than by analysis: how well is the internal network path from the load balancer to the backend servers controlled?

In traditional perimeter-based network architectures, the internal network was considered trusted because it was inside the firewall. An attacker who breached the perimeter was considered to have already won. The internal network was relatively flat, and controls inside it were minimal. This model is why TLS termination became the default: the internal network was trusted, so plaintext traffic inside it was acceptable.

That assumption has not held for most organizations for at least a decade. Lateral movement is the standard post-breach attack pattern. An attacker who compromises a low-value internal system uses it as a pivot point to reach higher-value targets. If the internal network is flat and load-balancer-to-backend traffic is plaintext, an attacker with a foothold anywhere on that network segment can capture authentication tokens, session cookies, API keys, and sensitive application data from every request flowing through the load balancer.

Zero-trust architecture explicitly rejects the trusted-internal-network assumption. In a zero-trust model, no network segment is inherently trusted; every connection must be authenticated and encrypted regardless of whether it is internal or external. Under this model, TLS bridging (re-encrypting to backends) or TLS passthrough is the only appropriate SSL handling mode.

The statement that TLS termination is secure because the internal network is private deserves scrutiny in every architecture review. The relevant questions are: can hosts other than the load balancer and the target backends route traffic on the load-balancer-to-backend subnet? Can an attacker who compromises any host in the environment reach that subnet? Does the organization have monitoring that detects unexpected traffic on that subnet? If the honest answer to any of these is uncertain, TLS bridging should be the default, not TLS termination.

Controls That Mitigate the Risk of TLS Termination

Where TLS termination is used and re-encryption to backends is not configured, the following controls reduce the risk from internal plaintext traffic exposure. These are mitigations, not equivalents to TLS bridging.

• Network segmentation: Place the load balancer and backend servers on a dedicated subnet with host-based and network-level firewall rules that permit traffic only between the load balancer and the backends on the HTTPS backend port. No other hosts should be able to reach the backend servers on the application port.
• Mutual TLS between load balancer and backends: Some load balancers support client certificate authentication on the backend connection even when sending plaintext HTTP. This authenticates the load balancer to the backend, ensuring that only the authorized load balancer can send requests, blocking an attacker who manages to reach the backend network.
• East-west traffic monitoring: Deploy network monitoring or an IDS on the load-balancer-to-backend segment. Unexpected connections to the backend application port from hosts other than the load balancer should trigger alerts.
• Backend access restriction to load balancer IPs: Configure the backend servers’ host-based firewall or security group rules to accept application-port connections only from the load balancer’s IP address. Block all other sources.
• Short-lived session tokens: If plaintext tokens captured from the internal network are a concern, reduce their useful lifetime. A session token that expires in 15 minutes rather than 24 hours limits the window of exploitation from captured credentials.

SSL Offloading and Certificate Management

One of the practical benefits of SSL offloading that security teams frequently cite is centralized certificate management. In a deployment where the load balancer terminates TLS, only the load balancer holds the SSL certificate and private key. Backend servers require no certificate configuration. Renewing the certificate, updating cipher suites, or changing TLS policy requires changes to one device rather than every backend server in the pool.

This is operationally significant. Certificate expiry incidents frequently occur because a certificate was installed on multiple servers and tracking renewal across all of them failed. When only one device holds the certificate, the renewal scope is narrowed to a single management point.

In TLS bridging mode, certificates exist at two points: the client-facing certificate on the load balancer and the backend certificate on the origin servers. The client-facing certificate is a publicly trusted certificate from a CA. The backend certificate can be a private CA certificate if the backends are internal and only accessed through the load balancer. Cloudflare’s Origin Certificate (described in the Cloudflare SSL article in this series) is exactly this pattern: a certificate trusted only by Cloudflare’s edge, used to authenticate and encrypt the Cloudflare-to-origin connection.

The Performance Case: Why Offloading Matters at Scale

The performance argument for SSL offloading is valid and worth understanding precisely. The TLS 1.3 handshake requires one round trip and involves ECDHE key exchange (elliptic curve Diffie-Hellman ephemeral) plus digital signature operations. On modern server hardware these are fast but not free. Under high connection rates, particularly for connections that are short-lived or frequently re-established, the handshake cost accumulates.

More significant is the asymmetric workload distribution in TLS. Asymmetric operations (handshake, key exchange) are orders of magnitude more expensive per bit than symmetric encryption (AES-GCM for session data). Modern hardware with AES-NI acceleration handles symmetric encryption at near-wire speed. The handshake overhead per new connection is the constraint. A server handling 10,000 new TLS connections per second is performing 10,000 asymmetric key exchange operations per second, which is a meaningful CPU load.

SSL offloading devices address this in two ways. Dedicated hardware SSL offloading appliances (F5 BIG-IP, Citrix ADC) include cryptographic accelerator chips that perform asymmetric operations faster than general-purpose CPUs. Software-based offloading at a load balancer like Nginx or HAProxy concentrates TLS work at a point that can be vertically or horizontally scaled independently of application server capacity. In cloud environments, managed load balancers (AWS ALB, Google Cloud Load Balancing) handle TLS termination in the provider’s infrastructure, leaving application instances to serve application logic only.

SSL Offloading in Regulated Environments

PCI DSS, HIPAA, SOC 2, and similar frameworks require encryption of sensitive data in transit. The specific question for SSL offloading deployments is whether plaintext traffic on an internal network segment constitutes a violation.

PCI DSS v4.0.1 Requirement 4.2.1 requires that strong cryptography is used to safeguard PAN during transmission over open, public networks. The internal network between a load balancer and backend servers that is properly segmented and access-controlled is generally not classified as an open, public network. However, the specific network architecture and the controls in place determine the analysis. Organizations subject to PCI DSS that use TLS termination without re-encryption must be prepared to demonstrate to their QSA that the internal segment is adequately controlled.

HIPAA’s Security Rule requires reasonable and appropriate administrative, physical, and technical safeguards for ePHI in transit. In practice, auditors reviewing SSL termination configurations typically require that either the internal segment is encrypted (TLS bridging) or that documented compensating controls demonstrate equivalent protection (network segmentation, monitoring, access restriction). Organizations handling ePHI with TLS termination without re-encryption carry compliance risk that depends on the thoroughness of their compensating controls documentation.

For the strongest compliance posture with the least interpretation risk, TLS bridging satisfies in-transit encryption requirements across all these frameworks without requiring compensating controls justification.

Configuring TLS Termination and Bridging in Nginx

Nginx serves as both a TLS termination point and a TLS bridging device depending on how the backend proxy is configured.

TLS termination (proxy to backend over HTTP)

TLS bridging (proxy to backend over HTTPS)

Change proxy_pass to use https:// and configure certificate verification for the backend connection:

The proxy_ssl_verify on directive in the TLS bridging configuration ensures Nginx validates the backend certificate, not just encrypts the connection. Without certificate validation on the backend connection, TLS bridging degrades to an encrypted tunnel with no authentication, which does not prevent a MITM on the internal network from intercepting the backend connection.

Frequently Asked Questions

What is SSL offloading?

SSL offloading is the practice of handling TLS handshakes and encryption operations at a dedicated network device such as a load balancer or reverse proxy rather than at backend application servers. The offloading device terminates the encrypted connection from clients, optionally inspects or routes the traffic, and forwards requests to backends either as plaintext (TLS termination) or re-encrypted (TLS bridging). Benefits include reduced CPU load on application servers, centralized certificate management, and the ability to enforce TLS policy at a single point.

Is SSL offloading a security risk?

TLS termination introduces a plaintext segment between the load balancer and backend servers. Whether this is an acceptable risk depends on the security controls protecting that internal network path. In a well-segmented network with strict east-west traffic controls, host-based firewalls restricting backend access to the load balancer only, and monitoring for unexpected internal traffic, TLS termination is a broadly used and defensible architecture. In a flat network with inadequate lateral movement controls, it represents a meaningful exposure. TLS bridging eliminates the plaintext internal segment entirely and is the recommended mode when the internal network cannot be fully trusted.

What is the difference between SSL termination and SSL bridging?

SSL termination ends the encrypted connection at the load balancer and forwards plaintext to backends. SSL bridging also ends the inbound encrypted connection at the load balancer but then establishes a new encrypted TLS connection from the load balancer to each backend server. TLS bridging preserves end-to-end confidentiality at the cost of additional CPU overhead for managing two TLS sessions per client connection. Termination is more performant; bridging is more secure for environments where the internal network cannot be trusted.

Does SSL offloading affect my SSL certificate?

In TLS termination mode, the SSL certificate is installed only on the load balancer. Backend servers require no certificate configuration. Certificate renewal, cipher suite changes, and TLS policy updates happen only on the load balancer. In TLS bridging mode, the client-facing certificate remains on the load balancer, and a separate certificate is required on each backend server. The backend certificate can be from a private CA if the backends are accessed only through the load balancer. In TLS passthrough mode, the certificate is installed only on backend servers, as the load balancer never terminates the TLS connection.

Does SSL offloading work with HTTP/2?

Yes. HTTP/2 over TLS (which is how browsers use it in practice) terminates at the load balancer in the same way as HTTPS. The load balancer negotiates HTTP/2 with the client, decrypts the requests, and typically forwards them to backends over HTTP/1.1 or HTTP/2 depending on the backend configuration. Modern load balancers including Nginx, HAProxy, and AWS ALB support HTTP/2 termination. HTTP/3, which uses QUIC over UDP, is also supported at the termination layer in newer versions of Nginx and cloud load balancer services, with the same security considerations applying to the backend connection.