This chapter describes how to configure SSL support. This chapter includes the following sections:

This chapter requires that you be familiar with the SSL protocol.

The Riverbed SSL solution optimizes data transfers that are encrypted using SSL, provided that SteelHeads are deployed locally to both the client-side and server-side of the network. All of the same optimized connections that are applied to normal nonencrypted TCP traffic, you can also apply to encrypted SSL traffic. SteelHeads accomplish this without compromising end-to-end security and the established trust model. Your private keys remain in the data center and are not exposed in the remote branch office location where they might be compromised.

The Riverbed SSL solution starts with SteelHeads that have a configured trust relationship, enabling them to exchange information securely over their own dedicated SSL connection. Each client uses unchanged server addresses and each server uses unchanged client addresses; no application changes or explicit proxy configuration is required. Riverbed uses a unique technique to split the SSL handshake.

The handshake is the sequence of message exchanges at the start of an SSL connection. In an ordinary SSL handshake, the client and server first establish identity using public-key cryptography, and then they negotiate a symmetric session key to use for data transfer. When you use Riverbed's SSL optimization, the initial SSL message exchanges take place between the client application (for example, a web browser) and the server-side SteelHead.

Prior to RiOS 6.0, the SSL handshakes from the client are always handled by the server-side SteelHead, including session reuse handshakes.

RiOS 6.0 or later provides an alternative strategy, called distributed termination, in which initial full handshakes are terminated on the server-side SteelHead, while subsequent reuse handshakes are terminated by the client-side SteelHead.

Distributed termination is enabled by default and is on the Optimization > SSL: Advanced Settings page. The time-out value specifies the amount of time the client can reuse a session with an SSL server after the initial connection ends. The range is 6 minutes to 24 hours. The default value is 10 hours.

Distributed termination improves performance by reducing the CPU load on the server-side SteelHead and shortens the key negotiation process by avoiding WAN round trips to the server. Distributed termination also shortens the key negotiation process by avoiding WAN round trips to the server. You can configure reuse of a client-side session for distributed termination on the Optimization > SSL: Advanced Settings page in the Management Console. For more information about distributed termination, see How SteelHeads Terminate an Optimized SSL Connection.

Riverbed has worked with large enterprise design partners to ensure that SSL optimization delivers real world benefits in real-world deployments, specifically:

The SteelHead has a secure vault that stores all SSL server settings, other certificates (that is, the CA, peering trusts, and peering certificates), and the peering private key. The secure vault protects your SSL private keys and certificates when the SteelHead is not powered on.

Initially the secure vault is keyed with a default password known only to the RiOS software. This allows the SteelHead to automatically unlock the vault during system start up. You can change the password, but the secure vault does not automatically unlock on start up. To optimize SSL connections, the secure vault must be unlocked.

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 use can SSL to transport HTTP traffic and provide one-way identification: only the web server authenticates itself to the web browser.

Figure: A Simple SSL Handshake 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 it 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-side 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 the 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 behavior discourages any tampering at the branch office.

The following list describes distributed termination:

Figure: Typical Data Transfer Operations on SSL Connections Optimized by SteelHeads 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: Time Sequence Diagram shows in time sequence the complete set of actions to set up an SSL connection.

This section describes how to deploy SSL optimization on SteelHeads and provides common configuration examples. This section includes the following topics:

You need the following SSL components to deploy SSL on SteelHeads:

U.S. export restrictions require that this license is installed on each SteelHead that has SSL optimization enabled. You can acquire an enhanced cryptography license key by filling out the online form available at http://sslcert.riverbed.com.

The proxy certificate is the certificate you configure on the server-side SteelHead for the server. Do not confuse this certificate with the certificate used for the secure inner channel or secure peering between the two SteelHeads and, also, the server certificate that is installed on the web and the application server.

The proxy certificate can be self-signed, signed by a well-known CA, or signed by your organization's own CA. It can be the same as, or different from, the certificate used by the actual server. The correct type of certificate depends on your deployment.

You can use a single wild card certificate and its private key as the proxy certificate for multiple servers.

For example, you might have three distinct servers using different certificates: sales.riverbed.com, internal.riverbed.com, and marketing.riverbed.com. You can add each of the three server certificates (as the proxy certificates) and their corresponding private keys, or you can add a single wild card certificate (*.riverbed.com) with its private key.

RiOS 6.0 and later simplify the SSL configuration process because the server-side SteelHead does not need to have a proxy certificate for each server individually. Prior to 6.0, you had to provide an IP address, port, and certificate to enable SSL optimization for a server. This method is impractical in cases where multiple servers shared the same server certificate because each server had to have a corresponding entry on the server-side SteelHead.

In RiOS 6.0 and later, you simply add unique proxy certificates to a certificate pool on the server-side SteelHead. When a client initiates an SSL connection with a server, the SteelHead matches the common name of the certificate on the server with one in its proxy certificate pool. If it finds a match, it adds the server to the list of optimizable servers, and all subsequent connections to that server are optimized with the same proxy certificate.

If it does not find a match, it adds the server name to the list of bypassed servers and all subsequent connections to that server are not optimized. The optimizable and bypassed server lists appear on the server-side SteelHead SSL Main Settings page of the Management Console.

If your proxy certificate and private key are in a format other than PEM, PCKS12, or DER, you must convert the certificate and key before you import them. The file extension does not necessarily dictate the encoding, as many common extensions such as .crt, .cer or .key can be either PEM or DER encoded.

To convert a certificate and private key, Riverbed recommends using an open source toolkit such as OpenSSL. For details, go to http://www.openssl.org/.

For information about converting a Base64 encoded PCKS12 certificate to PEM, see the Riverbed Knowledge Base article Converting a PCKS12 Certificate/Key to PEM at https://supportkb.riverbed.com/support/index?page=content&id=S13301.

You can use intermediary certificates instead of signing all certificates with a root level certificate. In releases earlier than RiOS 5.5, you needed to put all of the intermediate certificates on the server-side SteelHead and keep them up-to-date. With RiOS 5.5 or later, you can configure the server-side SteelHead to automatically pull down intermediate certificates from the back-end server.

Use the following command on the server-side SteelHead to enable certificate chain discovery:

Alternatively you can use the Management Console to enable certificate chain discovery. Choose Optimization > SSL: Advanced Settings and select Enable SSL Server Certificate Chain Discovery. By default, this option is disabled.

Before the server-side SteelHead can establish an SSL connection to the server, it needs to verify the authenticity of the server certificate. This verification is based upon the model of trust relationships established within a public key infrastructure.

In this model, the issuer of the certificate is a third party that is trusted by both the subject (owner) of the certificate and the party (client) relying on the certificate. A certificate authority (CA) is an entity that issues a certificate. A client establishes a trust relationship to the CA first and, subsequently, uses the certificate of the CA to verify the authenticity of a server certificate. A SteelHead establishing an SSL connection acts as a client.

A SteelHead includes a list of commonly used public CA certificates preinstalled. When the certificate of your server is signed by a private CA, you must install that private CA certificate in the server-side SteelHead. This certificate establishes the trust relationship to the private CA and, consequently, the server certificates that this private CA issues.

Each SteelHead participating in SSL optimization requires a peer certificate. The peer certificates allow the client-side and server-side SteelHeads to establish a secure inner channel. You can distribute these certificates several different ways: manual cut-and-paste; using the white, gray, and black peering lists; or through the SCC.

The peer certificates between the SteelHeads can be, and in most cases are, self-signed certificates. The session keys derived between the SteelHeads are used for encrypting data within the secure inner channel. The encrypted data ensures that the SSL session is secure end to end. For details, see Overview of SSL.

This section describes a simple deployment to help you set up, test, and understand basic SSL optimization functionality. This simple deployment chooses simplicity over security and installs a self-signed proxy certificate on the server-side SteelHead. You can test this deployment against an operational web server that uses SSL.

To complete this deployment, you need two SteelHeads, a WAN simulator, a LAN connection between the client and client-side SteelHead, and another LAN connection between the server and the server-side SteelHead. This example uses a self-signed certificate; however, the configuration steps remain the same for a CA-signed certificate.

This deployment assumes that your web server is configured for SSL connections and is running and that the client-side and the server-side SteelHeads can optimize non-SSL TCP traffic.

For information about troubleshooting and verification, see Troubleshooting and Verification.

The SteelHeads are capable of automatically detecting and configuring secure peering (SSL) between themselves if they are both using self-signed secure peering certificates. If SSL optimization is correctly configured on both the client-side and server-side SteelHeads, the self-signed secure peering certificate of the client-side SteelHead automatically populates into the server-side SteelHead self-signed peer gray list (Figure: Self-Signed Peer Gray List) and vice versa after an SSL connection is attempted across the SteelHeads. Use the drop-down menu to move the peer SteelHead into either self-signed peer white list or self-signed peer black list.

For more information, see Secure Peering Using the Self-Signed Peer White, Gray, and Black Lists.

The client uses the proxy certificate to secure the SSL session instead of the server certificate in a SteelHead optimized SSL connection. This usage is because of the way the SteelHead terminates an optimized SSL connection. For more information, see How SteelHeads Terminate an Optimized SSL Connection.

The following table shows the four options available for generating the proxy certificate and its private key. The proxy certificate and its private key are installed in the server-side SteelHead. To optimize an SSL session, a proxy certificate for the server is required.

In an optimized SSL session, the client receives the proxy certificate instead of the server certificate. The proxy certificate might or might not be the same as the server certificate. This scenario is the same for its private key. Nonetheless, the choice of proxy certificate is transparent to the client as the server common name in both certificates is the same, and the connection is secure end-to-end.

For more information, see How SteelHeads Terminate an Optimized SSL Connection and Proxy Certificate and Private Key.

You can use the following methods to configure the peer certificates used for secure peering (SSL) between the client-side and server-side SteelHeads:

You can use peering lists to configure peer certificates on SteelHeads running RiOS 5.0 or later. When SSL optimization is enabled, and an optimizable SSL connection is attempted across the SteelHeads, the remote peer is detected and its peering certificate is automatically populated into the self-signed peer gray list. The connection remains unoptimized because the remote peer is listed in the self-signed peer gray list.

You can examine the peer certificate for authenticity and move any peer from the gray list to either the white list or the black list. If you trust the remote peer, move it into the self-signed peer white list to begin optimizing the SSL connection. If you do not trust the remote peer, move it into the self-signed peer black list to prevent the SSL connection from being optimized.

Figure: Self-Signed Peer Gray List shows how you can move the peer certificate into either the white or black list with the drop-down menu.

To verify that the SSL connection is successfully optimized after you have configured secure peering, view the connection in Reports > Networking: Current Connections. For information about verifying SSL connections, see Troubleshooting and Verification.

If you use CA-signed peer certificates, you can configure the SteelHead to trust the CA certificate instead of the peer certificate. The SteelHead implicitly trusts all certificates that the trusted CA issues. Alternatively, you can manually add the peer certificate into the peering trust list.

If you have an intermediary CA, you must add them with the root CA. In secure peering, both the client-side and server-side SteelHead functions as an SSL client and server at the same time. For more details, go to https://supportkb.riverbed.com/support/index?page=content&id=S14925.

Riverbed recommends that you configure a medium-to-large SteelHead deployment for SSL optimization with the help of an SCC. The SCC can simplify the configuration of SSL optimization and secure peering and increase the operational efficiency of a SteelHead deployment through central management thereby enabling the deployment size to easily scale.

The configuration effort required to manage the secure peering certificates and trusts in a SteelHead deployment increases proportionally with the number of SteelHeads deployed. The increase is due to the following reasons:

A secure inner channel must be set up between the client-side and server-side SteelHeads in a deployment where SSL traffic or any other secure protocol traffic, such as signed-SMB and encrypted-MAPI, are optimized. Secure protocol traffic, including SSL traffic, are passed through the secure inner channel to maintain end-to-end data security. SCC 8.6 and later incorporate a certificate authority that can be used to centrally issue, distribute, and manage the secure peering certificates and peering trusts, in addition to the proxy certificates for SSL optimization. Using and trusting only CA-signed certificates increases the security model of an SSL deployment.

For information about using the SCC CA to manage the secure peering certificates and trust, see the SteelCentral Controller for SteelHead Deployment Guide. For information about adding a certificate authority to the secure peering trust configuration, see Secure Peering with CA-Signed Certificates.

In a high-security environment, you might want only known and trusted SteelHeads to peer for optimized traffic flows. Prior to RiOS 6.0, you could control peering only by modifying the peering tables, which was limiting because a secure model of peering trust could not be established between the SteelHeads. Modifying the peering tables creates situations in which SteelHeads can peer and optimize flows that might not be explicitly trusted. Using SSL secure peering, and forcing all traffic flows to flow through the secure inner channel, you can create an environment of explicit trust—only SteelHeads that can trust its peers can peer and optimize traffic flows.

In federated networks, it is common for organizationally separate SteelHeads to be aware of each other. If you use only secure peering, you create an environment of trust between the SteelHeads. If the secure inner channel connection fails, all conversations between the SteelHeads pass through. For more information about setting up secure peering, see Setting Up a Simple SSL Optimization Deployment or SteelHead Secure Peering Scenarios.

Figure: Trusted Peers shows a client connection to a server. The default behavior of the SteelHead is to optimize this connection. In an environment in which secure peering is used for all optimized traffic, the SteelHeads have to trust each other before a secure inner channel can be established to carry the optimized traffic. Use the following procedure to set up a SteelHead to secure all optimized traffic and only optimize through a secure inner channel.

If you select All from the Traffic Type you can cause up to a 10% performance decline in higher-capacity SteelHeads. Take this performance metric into account when sizing a complete secure SteelHead peering environment.

This section describes the advanced SSL feature set:

Client certificate support enables optimization of SSL traffic to SSL servers that authenticate SSL clients. The SSL server verifies the SSL client certificate. In the client authentication SSL handshake, each client has a unique client certificate and the SSL server, in most cases, maintains the state that is specific to each client when answering the client's requests. The SSL server must receive exactly the same certificate that is originally issued for a client on all the connections between the client and the server. Typically the client's unique certificate and private key are stored on a smart card, such as a Common Access Card (CAC), or on a similar location that is inaccessible to other devices on the network.

Enabling the client authentication feature allows SteelHeads to compute the encryption key and the SSL server continues to authenticate the original SSL client exactly as it would without the SteelHeads. The server-side SteelHead observes the SSL handshake messages as they go back and forth. With access to the SSL server's private key, the SteelHead computes the session key exactly as the SSL server does. The SSL server continues to perform the actual verification of the client, so any dependencies on the uniqueness of the client certificate for correct operation of the application are met. Because the SteelHead does not modify any of the certificates (or the handshake messages) exchanged between the client and the server, there is no change to their trust model. The client and server continue to trust the same set of CAs as they did without the SteelHeads optimizing their traffic.

Client authentication is also supported as part of a Mobile Controller deployment. You must have SteelHead Mobile 4.6 or later. For more information specific to the Mobile Controller, see the SteelHead Deployment Guide.

If the data center has a mixed environment with a few SSL servers that authenticate clients along with those that do not authenticate clients, Riverbed recommends enabling client authentication.

There are a few caveats when using client-side certificates:

Figure: SSL Server Authenticates the SSL Client shows the time sequence of actions to set up an SSL connection in which the SSL server authenticates the SSL client.

To verify client authentication, on the server-side SteelHead, check the Discovered Server (Optimizable) table on the SSL Main Settings page. Optimizable servers that are using client authentication appear as optimizable streams. For servers that are not using client authentication, the server appears in the Discovered Server (bypassed, not optimizable streams) table with the reason No proxy certificate configured for the server.

RiOS 7.0 or later includes support for enterprise proxy servers that route web traffic (including secure SSL web traffic) on behalf of clients to a secure SSL server.

For more information, including a configuration example, see Configuring HTTP SSL Proxy Interception.

RiOS 7.0 or later supports mid-session SSL support. A normal SSL session starts with an SSL handshake. The rest of the session is encrypted using session keys until the session is torn down. There are some scenarios where the session starts unencrypted but might need to encrypt certain traffic during the session. In these scenarios, an SSL handshake occurs mid-session to secure the specific traffic.

An example mid-session SSL is START Transport Layer Security (TLS) during SMTP sessions. The client starts an unencrypted SMTP session on port 25, to the server. The server accepts the unencrypted session and indicates to the client that it supports STARTTLS. In the middle of session, the client initiates STARTTLS. Normal TLS negotiations resume and the rest of the conversation is encrypted. For more details, go to http://en.wikipedia.org/wiki/STARTTLS.

RiOS 8.6 and later support TLS versions 1.0, 1.1, and 1.2. Note that the SteelHead can negotiate to earlier versions of TLS if the peer SteelHead uses a RiOS release prior to 8.6.

Server name indication (SNI) is an extension to the TLS protocol (RFC 6066) by which a client indicates which hostname it is attempting to connect to at the start of the TLS handshake process. This extension allows a server that hosts multiple hostnames (also known as name-based virtual hosting) using a single IP address to present the correct SSL/TLS certificate to the client. The hostname is the fully qualified DNS hostname of the server, as understood by the client.

When a client makes an HTTP connection to a server, the hostname is indicated in the HTTP request. However, when a client makes an HTTPS connection, the hostname is not sent until the secure connection is established. SNI allows a client to include the hostname that it is requesting in the TLS Hello message. This message allows the server to determine the correct named virtual host to service the request.

The following is an example from a packet capture illustrating the SNI in the client SSL-Hello message:

Without the SNI extension from a client application, the server returns the default certificate that matches the server IP. The challenge is that this certificate might or might not be the hostname that the client has requested. Browsers pop up a warning message when it receives a certificate with a different hostname than that it requested, and client-based applications might disconnect.

You must use client applications (for example, browsers) and servers that have end-to-end support for SNI. You must enable SNI on the server-side SteelHead if you want to intercept every HTTPS/TLS connection to determine the virtual hostname that the client is requesting in the SNI extension. Enabling SNI on the server side ensures that the server-side SteelHead selects and returns an acceptable proxy certificate to the client. No configuration is necessary on the client-side SteelHead.

In RiOS 9.2 and later, you do not need to enable SNI support for the following dependencies. The SteelHead always:

You must enable SNI support on the Management Console to intercept every HTTPS/TLS connection to determine the virtual hostname that the client is requesting in the SNI extension.

To prevent unnecessary intercepts, Riverbed recommends that you bypass traffic from nonoptimizable hostnames by IP addresses using an in-path rule because intercepting the HTTPS/TLS connection to determine the virtual hostname consumes a connection count even if the connection is eventually bypassed. This consumption has an impact on the SteelHead licensed connection limit, especially in environments in which only a small percentage of HTTPS/TLS traffic is optimized and no bypass rules are configured for the rest of the traffic from the unoptimizable hostnames.

SteelHead Mobile 2.0x or later supports SSL optimization similar in function to that of a client-side SteelHead. SteelHead Mobile relies on the Mobile Controller to configure SSL optimization policies and secure peering. For more details on configuring SSL optimization with SteelHead Mobile, refer to the SteelCentral Controller for SteelHead Mobile User’s Guide and the SteelHead Deployment Guide.

Use these tools to verify that you have configured SSL support correctly:

If you are experiencing issues with your SSL traffic being optimized, see the Riverbed Knowledge Base article Troubleshooting your SSL Configuration at http://supportkb.riverbed.com/support/index?page=content&id=S15107.

This section describes how to obtain the server certificate and private key on two web servers: Apache and Microsoft IIS. This section includes the following topics:

SSL is a protocol that enables the underlying application to transmit data securely over an insecure network. At the very foundation of SSL is the assumption that an authenticated party (for example, a web server) has exclusive access to its private key. If any other entity has this private key, it can mount a man-in-the-middle attack on a connection to the authenticated party.

SteelHeads optimize SSL traffic when you configure the server-side SteelHead with the server's certificate and private key, which enables it to intercept all SSL connections to the server.

The following procedures explain how to locate the Apache server certificate and private key and import them into the server-side SteelHead.

The following procedures explain how obtain the server certificate and private key from an IIS web server and import them into the server-side SteelHead.

Both the certificate and the private key are now stored in a single file with the filename you specified. The filename ends with the .pfx extension.

In certain situations you might not want to, or might not be able to, use the server's real private key. If that is the case, you can generate a self-signed certificate and private key pair for the server and install them on the server-side SteelHead. This certificate is not signed by any real certificate authority, but it is instead signed by the private key itself, and is thus called a self-signed certificate.

During SSL connection establishment, when the server-side SteelHead presents the self-signed certificate to the client (for example, a web browser), the client cannot verify the authenticity of the certificate. From the client's point of view, security might have been compromised, and you are typically alerted with a message to this effect.

A typical SSL-enabled Apache installation comes with a utility called OpenSSL, which you can use to generate the self-signed certificate. Enter the following command:

This command adds two files to the current directory, server.crt and server.key. These files correspond to the certificate and the private key, respectively. The next step is to import the files into the server-side SteelHead configuration.

If you want to generate a self-signed certificate for an IIS-based web server, you have two options.