When a user connects to a website or application over HTTPS, the traffic between them is encrypted. That protects the data in transit, but it also creates work: somewhere in the infrastructure, the traffic has to be decrypted before the application can actually process the request.
In a simple setup, each application server handles that work itself. As an application scales across multiple servers, there’s another option: move that responsibility to the load balancer or Application Delivery Controller (ADC) sitting in front of them, so one system handles encryption instead of every backend doing it independently. That’s the basic idea behind SSL offloading — the ADC handles the secure connection with the user, decrypts the incoming traffic, and forwards the request to the right application server.
But there’s a question that actually determines the architecture: after the ADC decrypts the traffic, what happens between the ADC and the backend? It can stay decrypted, get encrypted again, or never be decrypted at the load balancer at all. Those three possibilities are what this article covers.
Why Do We Talk About Both SSL and TLS?
Before going further, it’s worth clarifying one point. SSL is the older protocol; modern HTTPS connections actually run on its successor, TLS. Even so, the term SSL offloading remains widely used across the industry, so you’ll also come across TLS offloading and SSL/TLS offloading describing the same concept.
This article uses SSL offloading as the general term, and TLS specifically when referring to the modern encryption protocol behind HTTPS.
What Is SSL Offloading?
SSL offloading means moving the work of handling secure HTTPS connections away from application servers and onto another system — typically a load balancer or ADC. Instead of every server managing encryption and decryption for its own client connections, the ADC becomes the single point that terminates HTTPS and decides which backend receives each request.
Take an application running on five servers. Without offloading, each server manages secure connections from users on top of running the application itself. With SSL offloading, the ADC becomes the entry point instead:
That’s the shift: instead of five separate servers each managing their own encrypted connections, the ADC becomes the single point where those connections are handled.
This is why SSL offloading is closely tied to load balancing: the same component that distributes traffic across a server pool can also take on the encrypted connection before it routes each request.
How Does SSL Offloading Work?
It helps to think of the connection as two separate parts:
The first part is straightforward: the user’s browser establishes a secure HTTPS connection with the ADC. The second part is where infrastructure teams have a choice. From that point, there are three possible flows: the ADC can decrypt and forward plain HTTP, decrypt and re-encrypt before forwarding, or leave the connection encrypted and pass it straight through to the backend.
Here’s what each of those three flows looks like in practice.
Three Ways an ADC Can Handle Encrypted Traffic
1. Decrypt at the ADC and send HTTP to the backend
The ADC handles the secure connection with the user. After decrypting the request, it sends plain HTTP traffic to the selected backend. This is the clearest form of SSL offloading: the backend no longer handles encryption or decryption for the client connection, and certificate management for that public-facing connection can be centralized at the ADC.
The trade-off matters just as much: the connection between the ADC and backend isn’t encrypted. That can be acceptable in a controlled network environment, but not in every architecture.
2. Decrypt at the ADC and encrypt again (SSL bridging)
The ADC still decrypts the incoming request — but why decrypt it if it’s going to be encrypted again? Because there’s useful work to do in between. Once decrypted, the ADC can read the HTTP request, apply application-aware routing, or let a Web Application Firewall inspect it. Only after that processing does the ADC open a new encrypted connection to the backend.
This is commonly called SSL bridging or TLS re-encryption: the ADC decrypts traffic at the edge and re-encrypts it before sending it on to the web server. It’s a useful middle ground: the ADC gets visibility into application traffic while the connection to the backend stays encrypted.
3. Do not decrypt at the load balancer (SSL/TLS passthrough)
Here the load balancer never decrypts the application traffic — it forwards the encrypted connection to a backend server, which handles decryption itself. This is known as SSL or TLS passthrough.
Passthrough is useful when the secure connection needs to terminate directly on the application server. The trade-off is visibility: because the load balancer can’t see inside the encrypted connection, it can’t perform the same application-level inspection or content-based routing that decryption enables.
Why Use SSL Offloading?
SSL offloading brings several benefits beyond the architecture itself:
Centralized management
Managing public-facing certificates and encryption settings independently on every backend server creates operational overhead. Moving the client-facing HTTPS connection to the ADC creates a single control point for those connections.
Application-aware traffic management
Once traffic is decrypted, the ADC can read the actual HTTP request instead of just seeing an encrypted stream — which makes it possible to route based on hostname, URL, or HTTP headers.
Security inspection
The same visibility matters for application security. A WAF needs access to the HTTP request to analyze URLs, parameters, headers, or request bodies for malicious activity — which is why decryption and application security are closely linked.
Reduced backend workload
Moving client-facing encryption off the application servers frees up resources for the application itself. How significant that is depends on traffic volume and infrastructure — in modern environments, operational simplicity and traffic visibility can matter just as much as the raw CPU savings.
SSL Offloading vs SSL Termination vs SSL Bridging vs SSL Passthrough
One common source of confusion is SSL termination vs SSL offloading. Vendors often use them interchangeably, but they emphasize different things: termination tells you where an encrypted connection ends and gets decrypted; offloading emphasizes that the encryption work has moved away from another component — usually the backend.
This overlap shows up across the industry: many vendors describe SSL termination and SSL offloading as effectively interchangeable. We use similar language ourselves — our HTTPS listener performs SSL offloading, and our TLS/SSL Inspection flow refers to that decryption stage as TLS termination.
In practice, the vendor label matters less than the actual traffic flow. Rather than choosing an architecture based on whether something is called “offloading” or “termination,” ask where the traffic is decrypted and whether it’s encrypted again before reaching the application server.
Which Approach Should You Use?
The decision comes down to two questions: does the ADC need to inspect HTTP traffic, and does that traffic also need to stay encrypted on the way to the backend.
- Need HTTP/WAF visibility, and a plaintext backend connection is acceptable under your security policy → classic SSL offloading.
- Need HTTP/WAF visibility, but the backend connection also has to stay encrypted — for compliance, or because the network segment isn’t fully trusted → SSL bridging / re-encryption.
- The original secure connection needs to terminate only at the backend → passthrough.
There’s no universal “best” mode. The choice depends on the application’s security requirements, network boundaries, the ADC functionality you need, and your operational model.
Is SSL Offloading Secure?
SSL offloading doesn’t automatically make an architecture more or less secure — the important question is what happens after decryption.
With classic offloading, traffic between the ADC and backend can travel as plain HTTP, which means that network segment no longer carries encrypted data. Whether that’s appropriate isn’t just a question of whether the network is “internal” — it depends on your security policy, the trust boundaries of that network segment, and any compliance requirements that apply. If plaintext traffic isn’t acceptable, the ADC can decrypt the request for processing and then open a new encrypted connection toward the backend.
This also means the ADC itself becomes a security-critical component: it can access decrypted application traffic and manages the certificates used for those connections. Administrative access, updates, monitoring, and certificate management all matter as a result.
How SSL Offloading Works in SKUDONET
An HTTPS farm is a Layer 7 reverse-proxy service that handles secure HTTP traffic. When you use the HTTPS listener, the farm performs SSL offloading — moving the handling of client SSL/TLS connections away from the real application servers.
Decrypt, inspect, and control
TLS/SSL Inspection breaks this down into three stages:
The first stage is TLS termination — native TLS offloading. Once traffic is decrypted, Layer 7 security and traffic-management functions can operate on the request, which can then be re-encrypted before being forwarded to a backend when that architecture is required. This is also what makes WAF inspection possible on HTTPS traffic: our WAF checks requests only after the encrypted connection has been terminated, because it can’t inspect a payload that’s still encrypted.
Does the backend connection have to stay unencrypted?
No. Within an HTTP/S service, the HTTPS Backends option lets you encrypt traffic again before it reaches the backend servers:
This is documented as TLS Re-encryption to Backend — the same architecture described elsewhere as SSL bridging.
Centralized certificate management
Because we act as the HTTPS endpoint in this model, the HTTPS farm also manages the certificates and encryption settings tied to those client connections — SSL/TLS versions, cipher configuration, wildcard and SNI support, and Let’s Encrypt integration for automated renewal. Encryption management, load balancing, and application security inspection all happen at the same application delivery layer.
Conclusion
SSL offloading moves the handling of encrypted client connections from backend servers to the load balancer or ADC. What happens next — plaintext to the backend, re-encryption, or passthrough — is the part of the architecture that actually needs a decision, and it depends on where your organization needs traffic to stay encrypted, whether the ADC needs to see inside HTTP requests, and how you want to split that responsibility between the delivery layer and the backend.
On our platform, HTTPS farms provide SSL offloading at the application delivery layer, and TLS/SSL Inspection builds on the same model — decrypt, inspect, and re-encrypt — for teams that need both visibility and an encrypted path to the backend.
Want to see how SKUDONET can fit into your application delivery architecture? Explore SKUDONET Enterprise Edition.
FAQ
What is SSL offloading?
SSL offloading is the process of moving the handling of secure HTTPS connections from application servers to another system, typically a load balancer or Application Delivery Controller. The ADC decrypts the incoming connection and forwards the application request to a backend.
How does SSL offloading work on a load balancer?
The user establishes an HTTPS connection with the load balancer rather than directly with an application server. The load balancer decrypts the traffic, can process or inspect the HTTP request, and then forwards it to the selected backend.
What is the difference between SSL and TLS offloading?
SSL is the older protocol name that remains widely used in industry terminology such as “SSL offloading.” Modern HTTPS uses TLS. In today’s infrastructure, SSL offloading and TLS offloading generally refer to the same architectural concept.
What is the difference between SSL termination and SSL offloading?
SSL termination tells you where an encrypted connection is decrypted. SSL offloading emphasizes moving that processing away from the backend servers. Vendors often use the terms with some overlap, so checking the actual client-to-ADC and ADC-to-backend traffic flow is more reliable than relying on the label alone.
What is the difference between SSL offloading and SSL bridging?
In the classic SSL offloading model, the ADC decrypts HTTPS and can forward plaintext traffic to the backend. With SSL bridging or re-encryption, the ADC decrypts the request but creates a new encrypted connection before sending it to the backend.
What is SSL passthrough?
With SSL passthrough, the load balancer does not decrypt the HTTPS traffic. It forwards the encrypted connection to a backend server, where it is finally decrypted. This preserves backend control of the secure connection but limits the load balancer’s ability to inspect HTTP traffic.
Does SSL offloading improve server performance?
SSL offloading can reduce the encryption and decryption work performed by application servers. The actual performance impact depends on traffic volume, connection behavior, and infrastructure. Centralized certificate management and application visibility are also important reasons to use offloading.
Is SSL offloading secure?
It can be used securely, but the architecture must account for what happens after the ADC decrypts the request. If traffic to the backend isn’t encrypted, that network segment carries plaintext data. When that’s not appropriate, the traffic can be re-encrypted before being forwarded to the backend.
