What Is SSL Offloading?

Why Do We Need SSL Offloading?

The Internet provides us with endless information resources, but also has many hidden security risks. Take the commonly used HTTP as an example. As plaintext is used during the communication process, transmitted content can be intercepted or modified by a bad actor. To improve security, various encryption technologies have emerged. SSL is an encryption and authentication technology widely used on the Internet. HTTP over SSL is also known as HTTPS.

When HTTPS is used for communication, in addition to establishing TCP connections and sending HTTP packets, SSL communication is required. As a result, HTTPS communication is slower than HTTP communication. In addition, during SSL communication, both communication parties need to encrypt and decrypt transmitted data. Encryption and decryption calculations consume huge computing resources of a server, while longer keys consume even more resources. To lighten the load on the server, you can deploy dedicated hardware between the SSL client and server to replace the server for performing SSL handshake, encryption, and decryption. In this case, the server can focus on processing applications and services.

SSL offloading has the following advantages:

• It can offload communication and computing tasks from the server, reduce the SSL encryption and decryption load of the intranet server, and accelerate network communication.
  After the SSL offloading function is enabled, the device functions as a proxy SSL server to encrypt and decrypt SSL data. The restored HTTP traffic can be directly processed by the intranet server, greatly lightening the processing load on the intranet server and accelerating network communication.

  
  Reducing the SSL encryption and decryption load of the intranet server
• After restoring HTTPS traffic to HTTP traffic, the device can configure server load balancing (SLB) on the HTTP traffic to implement refined traffic scheduling and focus on main functions of the traffic.

  As a growing number of intranet servers provide HTTPS services for external systems, the original SLB cannot extract necessary fields from HTTPS traffic for refined traffic scheduling. As a result, traffic can only be randomly allocated. After the SSL offloading function is enabled, the device can restore HTTPS traffic to HTTP traffic. In this case, the device can implement HTTP cookie-based sticky sessions and schedule real server groups based on HTTP packet headers.

  
  Policy scheduling and session stickiness based on HTTP fields

How Does SSL Offloading Work?

SSL offloading works in either of the following ways:

• SSL termination

  A device is deployed in front of the server and has the SSL offloading function enabled. When a client initiates an HTTPS connection, the device functions as a proxy SSL server to encrypt and decrypt SSL data. The device terminates the SSL connection, restores the HTTP service, and establishes an HTTP connection in plaintext with the server. The server then sends a response packet to the device, which encrypts the packet before sending it back to the client.

  
  SSL termination
• SSL bridging

  The working principle of SSL bridging is similar to that of SSL termination. When a client initiates an HTTPS connection, the device functions as a proxy SSL server to encrypt and decrypt SSL data and restore HTTP services. The difference is that the device encrypts the data again before sending it to the server, ensuring intranet data security after the SSL offloading configuration.

  
  SSL bridging

Huawei SSL Offloading Solution

If a server processes only HTTP service data, you can configure an SSL decryption profile on the load balancer to implement SSL offloading. The load balancer performs load balancing and session stickiness for HTTP packets in plaintext, selects a real server from the real server group using the load balancing algorithm, and sets up an HTTP connection with that server. This helps reduce the CPU load on the server for processing SSL negotiation, encryption, and decryption, thus improving the server performance. If the server only receives HTTPS packets to ensure the intranet data security after the SSL configuration, you can configure the HTTP SLB and then configure an SSL encryption policy to encrypt traffic before sending it to the server.