SteelHead™ Deployment Guide - Protocols : SSL Deployments : Overview of SSL
Overview of SSL
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.
The SSL features have changed with each release of RiOS. If you are running a version of RiOS that is earlier than v6.0, consult the appropriate documentation for that software release.
Figure 11‑2 shows a simplified SSL handshake where the server authenticates itself to the client.
Figure 11‑2. A Simple SSL Handshake
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.
How SteelHeads Terminate an Optimized SSL Connection
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):
  • A certificate and private key pair for the server. This certificate and private key pair does not have to be the same as the one used by the actual server. In a production environment, it would typically be signed by a CA trusted by the client. You can import a signed server certificate into a SteelHead without a private key if you have used the same SteelHead to generate the certificate signing request for that server certificate.
  • For more details, see Importing CA signed certificate - based on the CSR generated by SteelHead at
    To avoid confusion, in this chapter, the certificate residing on the server-side SteelHead (for the server), is referred to as the proxy certificate. The proxy certificate might or might not be the same as the actual server certificate, but it serves the same function. The one exception is if you use client certificates. For details, see Client Certificate Support.
  • The certificate of the client-side SteelHead.
  • 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:
  • Full SSL handshakes terminate on the server-side SteelHead.
  • The master secret containing information that allows the computation of the session key for reusing the session is transported to the session cache of the client-side SteelHead.
  • The subsequent handshakes are reused and terminate on the client-side SteelHead.
  • 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:
  • kc is the session key between the client initiating the transmission and the server-side SteelHead.
  • ks is the session key between the server-side SteelHead and the server.
  • kt is the session key between the client-side SteelHead and the server-side SteelHead for the SSL secure inner channel.
  • Figure 11‑3. Typical Data Transfer Operations on SSL Connections Optimized by SteelHeads
    Figure 11‑4 shows in time sequence the complete set of actions to set up an SSL connection.
    Figure 11‑4. Time Sequence Diagram