Because a complete description of SSL is outside the scope of this guide, this section provides a brief overview of the relevant components of SSL security.

SSL provides a way for client and server applications to communicate securely over a potentially insecure network. It provides authentication, and prevents eavesdropping and tampering. In the most common use case, you can SSL to transport HTTP traffic, and provide one-way identification: only the Web server authenticates itself to the Web browser.

Figure 11‑2 shows a simplified SSL handshake where the server authenticates itself to the client.

In response to the Hello message, the server sends back its certificate. The certificate contains the server's public key, some identifying information about the server (such as its name and location), and a digital signature of all this information. This digital signature is issued by an entity called a Certificate Authority (CA) that both the client and the server trust, and serves as proof that no one has tampered with the certificate.

Upon receiving the certificate, the client verifies that it has not been tampered with and that it does belong to that particular server. Then, the client generates a random number N, encrypts it with the server's public key, and sends it to the server. At this point, both the client and the server use the same function to derive the session key, ks, from N. In the simplest case, after the initial SSL handshake between the client and the server, and the creation of the session keys, the same session keys are used for the duration of the session, without the need to go through another SSL handshake.

At a high level, SteelHeads terminate an optimized SSL connection by making the client think it is communicating to the server and making the server think it is talking to the client. In fact, the client is talking securely to the SteelHeads. You require some special provisioning to accomplish optimization that appears transparent to the client.

To enable SSL connection termination, you must configure the server-side SteelHead to include proxy certificates and private keys for the purpose of emulating the server. For details, see Generating the Proxy Certificate and Private Key Pair. When the SteelHead poses as the server, there does not need to be any change to either the client or the server. The security model is not compromised—the optimized SSL connection continues to guarantees server-side authentication, and prevents eavesdropping and tampering.

When transferring data over the WAN on behalf of an optimized SSL connection, the client and server-side SteelHeads ensure that their inner connection provides all the security features the original SSL connection would have, had it not been optimized. SteelHeads accomplish this by establishing their own SSL connection between themselves. To secure the inner SteelHead channel, you must configure each SteelHead with the certificate of the peer SteelHead (secure peering). There are various methods to accomplish a secure inner channel between the SteelHeads. The authentication is mutual, with the client initiating the connections to authenticate the server, and server authenticates the client. For more details, see SteelHead Secure Peering Scenarios.

To securely terminate an SSL connection to an SSL server, the following list is a high-level configuration for the server-side SteelHead (for more information about how to configure SSL on a SteelHead, see the SteelHead Management Console User’s Guide):

The client-side SteelHead has only the server-side SteelHead certificate for secure peering between the client-side and server-side SteelHeads. The client-side SteelHead does not need the certificates or keys of the server. This discourages any tampering at the branch office.

The following list describes distributed termination:

Figure 11‑3 shows a high-level view of application data crossing the network from the client to the server. After the SSL connection is terminated, there are only three session keys involved: kc, ks, and kt. The data is encrypted with session key kc; then it is decrypted, optimized, and reencrypted with session key kt for the SSL secure inner channel between the two SteelHeads:

Figure 11‑4 shows in time sequence the complete set of actions to set up an SSL connection.