SSL Offloading (or SSL Termination)
In this method, SSL/TLS traffic is terminated at the F5 BIG-IP system. The traffic is decrypted and can be inspected
and manipulated at the load balancer, then forwarded to the application servers over plain HTTP (no re-encryption to
the server). The BIG-IP maintains the SSL/TLS session with the client, while the server-side session is cleartext HTTP.
Pros:
-
Offloads the CPU-intensive encryption/decryption workload from the server, which can improve application server
performance and scalability. -
Enables traffic inspection and L7 control (headers, redirects, iRules logic, etc.) because the traffic is decrypted
at the BIG-IP. -
Enables security capabilities that require decrypted traffic inspection (e.g., F5 ASM/Advanced WAF), since BIG-IP can
evaluate the HTTP payload.
Cons:
-
Traffic between the load balancer and servers is not encrypted, which can be a risk if the server-side network
segment is not sufficiently trusted or controlled. -
Not suitable for environments where “encrypt to the node” or strict encryption requirements are mandated for the
server-side path.
SSL Bridging (or SSL Re-encryption)
In this method, SSL/TLS traffic is terminated at the F5 BIG-IP system, decrypted for inspection and L7 policy
enforcement, then re-encrypted and forwarded to the servers. BIG-IP maintains two separate SSL/TLS sessions: one
client-side (client to BIG-IP) and one server-side (BIG-IP to server). This is commonly called SSL bridging or TLS
re-encryption.
Pros:
-
Provides encryption on both legs (client-to-BIG-IP and BIG-IP-to-server), which supports “encrypt across the internal
segment” requirements while still enabling centralized control at the BIG-IP. -
Enables traffic inspection and L7 controls since the traffic is decrypted at the load balancer before being
re-encrypted. -
Enables security features that require decrypted traffic inspection (e.g., F5 ASM/Advanced WAF), while still keeping
the server-side path encrypted.
Cons:
-
Adds performance overhead compared to termination-only, because BIG-IP is handling two TLS sessions (decrypting and
re-encrypting). -
More operational complexity: backend TLS must be configured and maintained (certificates on the servers), and BIG-IP
must be configured to trust/validate the server-side certificates as required by your security standards. -
Important nuance: this is not “end-to-end” encryption in the strict cryptographic sense, because the BIG-IP is an
explicit termination point where traffic is decrypted for inspection before being re-encrypted.
SSL Passthrough
In this method, SSL/TLS traffic is not decrypted at the F5 BIG-IP system. The BIG-IP forwards the encrypted traffic to
the servers (typically at L4/TCP), and the servers handle the encryption/decryption. The SSL/TLS session remains
between the client and the server, with BIG-IP passing the encrypted traffic through.
Pros:
-
Maintains strict end-to-end encryption from client to server, which aligns well with environments that require the
TLS session to terminate only at the application. -
Reduces certificate management on BIG-IP (since BIG-IP is not terminating TLS for inbound connections in this model),
simplifying operations in certain designs.
Cons:
-
BIG-IP cannot inspect or manipulate HTTP content (headers/URI/cookies) because the traffic remains encrypted, which
limits L7 features. -
Security features that require decrypted inspection—such as F5 ASM/Advanced WAF—cannot be applied in a true
passthrough design. -
The encryption/decryption workload remains on the application servers, which can impact server CPU and scalability,
especially under high connection rates.
Each method has valid use cases, and the right choice depends on the trade-offs you’re willing to make across
performance, security/compliance, operational complexity, and the level of L7 control you need at the BIG-IP.
In practice, I see SSL bridging (TLS re-encryption) used most often when organizations want L7 visibility and WAF
enforcement but also have a formal requirement to encrypt traffic on the internal server-side segment.