Understanding Server Protection

Application Scenario

In the server protection scenario, the FW performs security detection on external encrypted traffic to protect internal servers on the enterprise network. In this scenario, the FW serves as a man-in-the-middle. After receiving a request from the client, the man-in-the-middle proxies a client to establish a connection with the server and meanwhile serves as a server to establish a connection with the client. This actually turns SSL handshake into two completely independent processes. Therefore, the FW serves as a man-in-the-middle to obtain the complete content in the interaction with the client and server so as to process the content.

In the server protection scenario, the FW needs to provide a server certificate for the client and obtain the symmetric key by using the server certificate private key to decrypt the encrypted packets sent by the client. Therefore, you need to import the server certificate and its private key to the FW, and then specify the server certificate as the internal server certificate.

As shown in Figure 1, a host on the Internet, serving a user (client), is affected by viruses, and the user needs to access an HTTPS server on the enterprise intranet. To protect the HTTPS server from being affected by external viruses, the network administrator enables SSL-encrypted traffic detection on the FW. When an HTTPS access request of the user reaches the FW, the FW decrypts the access request, checks the content of the decrypted data, and blocks the traffic once discovering viruses in the traffic. In this way, SSL-encrypted traffic detection protects the intranet server.

Figure 1 Server protection through SSL-encrypted traffic detection

Packet Processing in the Server Protection Scenario

Figure 2 shows the process for establishing SSL connections between the FW and a client and between the FW and a server, and the process for SSL-encrypted traffic decryption in the server protection scenario.

Figure 2 Diagram of SSL packet exchange in the server protection scenario

1. Import the server certificate and private key to the FW.
2. A client sends a Client Hello packet to initiate a new SSL connection.
3. The FW resolves and buffers the Client Hello packet sent from the client, and sends its own Client Hello packet to the server.
4. The server responds to the Client Hello packet and sends a Server Hello packet and a server certificate to the FW.
5. The FW implements SSL handshake with the server and establishes the SSL connection as a proxy client.

   After the SSL connection is established, the FW and the server negotiate a symmetric key. This symmetric key is used for encryption or decryption when service traffic is transmitted between the FW and the server.

6. The FW sends its own Server Hello packet and the server certificate imported in 1 to the client.
7. The client verifies the server certificate, implements SSL handshake with the FW, and establishes the SSL connection.

   After verifying the server certificate, the client generates a local symmetric key. After encrypting the symmetric key using the public key of the server certificate, the client sends the symmetric key to the FW. Upon receiving the encrypted symmetric key, the FW decrypts it using the private key in the server certificate generated in 1. This symmetric key is used for encryption or decryption when service traffic is transmitted between the client and the FW.

8. The client sends the SSL-encrypted (using the symmetric key) service traffic to the server.
9. The FW decrypts SSL service traffic sent from the client using the symmetric key, and checks the content security of the decrypted traffic.
10. The FW re-encrypts the traffic that passes the content security check to the server.

    The FW re-encrypts the symmetric key negotiated with the server. When the encrypted traffic reaches the server, the server decrypts the traffic using the symmetric key again.