SSL Offloading

What Is SSL Offloading?

SSL offloading is a technique for accelerating SSL. Given SSL's extensive use as an internet security measure, it can heavily tax server resources. Hence, SSL offloading shifts SSL negotiation, encryption, and decryption tasks from the primary server to the load balancer, thereby alleviating the server's burden.

Why Do We Need SSL Offloading?

The internet offers a vast array of information resources, yet it also harbors numerous hidden security threats. Consider the widespread use of HTTP, for instance. Due to the utilization of plaintext during transmission, data exchanged over HTTP can be intercepted or tampered with by malicious entities. To bolster security, various encryption technologies have emerged, with SSL standing out as a widely adopted encryption and authentication protocol on the web. When HTTP is augmented with SSL, it becomes HTTPS, a secure communication channel.

However, employing HTTPS entails more than just establishing TCP connections and transmitting HTTP packets; it necessitates SSL communication as well. Consequently, HTTPS communication tends to be slower compared to HTTP, as both communicating parties are tasked with encrypting and decrypting transmitted data. This encryption and decryption process places a significant computational burden on the server, especially with longer encryption keys consuming even more resources. To alleviate this strain on the server, dedicated hardware can be deployed between the SSL client and server, assuming the server's role in performing SSL handshake, encryption, and decryption tasks. This arrangement allows the server to concentrate on executing applications and services.

SSL offloading presents several advantages:

• Offloading communication and computational tasks from the server reduces the SSL encryption and decryption workload, thereby enhancing network communication speed.

• 

• By enabling SSL offloading, the device operates as a proxy SSL server, handling SSL data encryption and decryption. Consequently, the intranet server can directly process restored HTTP traffic, significantly reducing its processing burden and accelerating network communication.

Once HTTPS traffic is converted back to HTTP traffic, the device gains the capability to set up Server Load Balancing (SLB) specifically tailored for HTTP traffic, enabling precise traffic scheduling and prioritizing key traffic functions.

As the number of intranet servers offering HTTPS services to external systems continues to rise, the original SLB setup struggles to extract essential fields from HTTPS traffic for nuanced traffic scheduling. Consequently, traffic allocation remains largely arbitrary. However, with the SSL offloading function activated, the device can seamlessly convert HTTPS traffic into HTTP traffic. This allows for the implementation of HTTP cookie-based sticky sessions and the scheduling of real server groups based on HTTP packet headers, facilitating more targeted and efficient traffic management.

How Does SSL Offloading Work?

SSL offloading operates through one of two methods:

SSL termination

In this setup, a device equipped with SSL offloading capability is positioned ahead of the server. When a client initiates an HTTPS connection, the device acts as a proxy SSL server, handling the encryption and decryption of SSL data. It terminates the SSL connection, converts the communication back to HTTP, and establishes a plaintext HTTP connection with the server. Upon receiving a response packet from the server, the device encrypts it before forwarding it to the client.

SSL bridging

SSL bridging operates on a principle akin to SSL termination. In this scenario, as a client initiates an HTTPS connection, the device acts as a proxy SSL server, managing encryption and decryption of SSL data while restoring HTTP services. However, the distinguishing factor lies in the device re-encrypting the data before transmitting it to the server, thereby maintaining intranet data security post-SSL offloading configuration.