F5 – SSL Options (SSL Offloading vs SSL Bridging vs SSL Passthrough)
Consider a conventional client-server architecture in which you have a client and a web or application server. HTTPS is used to establish the connection (with SSL encryption). You probably haven’t considered the number of resources these servers must consume to decrypt, process, and re-encrypt client requests before sending them back to the clients.
The BIG-IP system manages decryption and re-encryption using the SSL Offloading technique. The client delivers encrypted traffic to BIG-IP utilizing this manner. As a result, the BIG-IP decrypts the client communication and sends the decrypted traffic to the server. The BIG-IP encrypts the communication from the server to the client and sends it back to the client. This eliminates the additional overhead of encryption and decryption on the server. All server resources can now be fully utilized for other purposes, such as serving application content or performing other tasks for which they were designed.
To summarize, SSL offloading on load balancers like BIG-IP LTM allows a web server to be relieved of the processing effort of encrypting and decrypting data.
SSL Re-Encryption or SSL Full Proxy are other terms for the same thing. The BIG-IP system accepts encrypted inbound traffic and decrypts it for traffic analysis purposes using this mechanism. However, it re-encrypts the connection before transmitting it to the destination servers. When the edge device performs a deep packet inspection to ensure that the contents of the SSL-encrypted transmission are safe, or when unencrypted traffic crossing the internal network poses a security risk, SSL bridging can be advantageous.
Important information regarding SSL Bridging:
Each site has its own SSL session.
Each segment’s communication is secure.
Secure ports, such as port 443, are configured on servers.
BIG-IP has the capacity to read the content of traffic.
All of the persistence settings are available.
SSL passthrough is one of the key configuration options for load balancing encrypted online traffic. Passing data through a load balancer to a server without decrypting it is known as SSL passthrough. The data is encrypted as it travels through the load balancer thanks to an SSL pass through. As a result, installing an SSL certificate on the load balancer is not required for proxy SSL passthrough settings. SSL certificates are installed on the backend server because the load balancer does not handle SSL connections.
In this case, it is the server that will perform the process of decrypting all incoming SSL traffic. Using SSL passthrough requires a higher processing unit on the part of the servers. This is why it is not recommended for larger deployments. It also restricts some capabilities of a load balancer. The SSL proxy pass-through does not inspect traffic or intercept SSL sessions on network devices before reaching the server, as it simply passes along encrypted data.
Let’s take a quick look at the configuration for this method on BIG-IP LTM. Because it’s only a pass-through, LTM can’t read the headers, which limits persistence. Only non-SSL information in the packet, such as the source and destination IP addresses, can be used to preserve persistence. Client SSL and Server SSL profiles should not be combined. Because you can’t use an HTTP profile to optimize layer seven traffic, you can’t use it. Cookie persistence isn’t an option.
This configuration is typically used when the apps being served cannot ingest encrypted traffic or when web application security is a concern.