Configuring SSL Server Certificates and Certificate Authorities
This section provides an overview of SSL support and describes how to configure SSL server certificates and certificate authorities. SSL is a cryptographic protocol that provides secure communications between two parties over the Internet.
Typically in a web-based application, it is the client that authenticates the server. To identify itself, an SSL certificate is installed on a web server and the client checks the credentials of the certificate to make sure it is valid and signed by a trusted third party. Trusted third parties that sign SSL certificates are called certificate authorities (CA).
How Does SSL Work?
With Riverbed SSL, SteelHeads are configured to have a trust relationship, so they can exchange information securely over an SSL connection. SSL clients and servers communicate with each other exactly as they do without SteelHeads; no changes are required for the client and server application, nor are they required for the configuration of proxies. RiOS splits up the SSL handshake, 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 negotiate a symmetric session key to be used for data transfer. With Riverbed SSL acceleration, the initial SSL message exchanges take place between the client and the server-side SteelHead.
Figure: Riverbed SSL
RiOS provides an alternative handshake, called distributed termination, which terminates full handshakes on the client-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 the client’s SSL connection is physically and logically terminated on the client-side SteelHead.
Distributed termination improves performance by lessening the CPU load because it eliminates expensive asymmetric key operations. It also shortens the key negotiation process by avoiding WAN roundtrips to the server. You can find the setting to reuse a client-side session for distributed termination in the Optimization > Advanced Settings page. See
Setting Advanced SSL Options.
In RiOS 6.1 and earlier, SSL optimization intercepts and optimizes SSL connections where only the SSL server uses a certificate. RiOS 6.5 and later provide client-side authentication, used to optimize SSL connections where the SSL server challenges the SSL client to present its own certificate, in addition to authenticating servers using SSL certificates. See
Configuring Advanced and SSL Cipher Settings.
The SteelHead also contains 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 isn’t powered on. You set a password for the secure vault that is used to unlock it when the SteelHead is powered on. After rebooting the SteelHead, SSL traffic isn’t optimized until the secure vault is unlocked with the correct password. See
Unlocking the Secure Vault.
Prerequisite Tasks
Complete these prerequisite tasks before you begin SSL configuration:
1. Connect to the Management Console using HTTPS to protect your SSL private keys and certificates.
2. On the client-side and server-side SteelHead, make sure you have a valid Enhanced Cryptography License Key. To verify your license, see
Managing Licenses and Model Upgrades. If you don’t have a valid Enhanced Cryptography License Key file, go to https://sslcert.riverbed.com and follow the procedures documented there.
Note: The SSL License is called the Enhanced Cryptographic License Key, because it also activates RiOS data store encryption and creates secure channels while optimizing encrypted MAPI and SMB-signed traffic (even if the SteelHeads aren’t configured for optimizing SSL traffic).
3. Back up your private keys and the CA-signed certificates before you begin the SSL configuration process.
Basic Steps
This section provides an overview of the basic steps to configure SSL, followed by detailed procedures.
Task | Reference |
1. Enable SSL support on the server-side and client-side SteelHeads. | |
2. Set the SSL secure vault password on the client-side and server-side SteelHead. | |
3. Optionally, enable the SteelHead to reuse the client-side SSL session. This is a client-side setting that improves connection setup performance. Both the client-side SteelHead and the server-side SteelHead must be running RiOS 6.0 or later. Enabling this option requires an optimization service restart. Client-side session reuse is enabled by default in RiOS 7.0 and later. | |
4. On the server-side SteelHead, configure a proxy certificate and private key for the SSL back-end server. This step enables the server-side SteelHead to act as a proxy for the back-end server, which is necessary to intercept the SSL connection and to optimize it. | |
5. Create an in-path rule for the client-side SteelHead. In-path configurations - Create a client-side in-path rule with the Preoptimization Policy = SSL. If you want to enable the HTTP latency optimization module for connections to this server, you add a corresponding in-path rule with Latency Optimization Policy = HTTP. Out-of-path configurations - On the client-side SteelHead, add a new in-path rule to identify which connections are to be intercepted and applied to SSL optimization. Use these property values: • Type - Fixed target • Destination Subnet/Port - We recommend you specify the exact SSL server IP address (for example, 10.11.41.14/32) and the default SSL port 443. • VLAN Tag - All • Preoptimization Policy - SSL • Data Reduction Policy - Normal • Latency Optimization Policy - HTTP Note: Latency optimization isn’t always HTTP, especially for applications that use the SSL protocol but aren’t HTTP based. In such cases, specify None for the latency optimization. • Neural Framing Mode - Always | |
6. Configure mutual peering trusts so the server-side SteelHead trusts the client-side SteelHead and vice versa. Use one of these approaches: Use the secure inner channel and peering lists: • Configure the inner channel SSL settings as described in Configuring Secure Peers. Both the client-side and server-side SteelHeads must be running RiOS 5.0 or later. • To automatically discover SteelHeads using self-signed certificates, open your secure application to send some traffic through the SteelHeads. The connection is passed through to the server without optimization, but the SteelHeads will automatically discover the peers and place them in the self-signed peer gray list. • Manually move the peers from the gray list to the trusted white list by simply marking them as trusted. The connections aren’t optimized until after you move the peers to the white list. • Reopen your secure application. —or— Add CA-signed peer certificates: • Add the PEM certificate of the designated CA as a new trusted entity to the peering trust list for each SteelHead. • For production networks with multiple SteelHeads, use the SCC or the bulk import and export feature to simplify configuring trusted peer relationships. For details, see the SteelCentral Controller for SteelHead User’s Guide or Performing Bulk Imports and Exports. Note: Your organization can choose to replace all of the default self-signed identity certificates and keys on their SteelHeads with those certificates signed by another CA (either internal to your organization or an external well-known CA). In such cases, every SteelHead must simply have the certificate of the designated CA (that signed all those SteelHead identity certificates) added as a new trusted entity. | |
7. If your organization uses internal CAs to sign their SSL server certificates you must import each of the certificates (in the chain) on to the
server-side SteelHead. You must perform this step if you use internal CAs because the SteelHead default list of well-known CAs (trusted by our server-side SteelHead) doesn’t include your internal CA certificate. To identify the certificate of your internal CA (in some cases, the chain of certificate authorities) go to your web browser repository of trusted-root or intermediate CAs: for example, Internet Explorer > Tools > Internet Options > Certificates. | |
8. On the client-side and server-side SteelHead, restart the optimization service. | |
Verifying SSL and Secure Inner Channel Optimization
Use these tools to verify that you have configured SSL support correctly:
• SSL Optimization - After completing the SSL configuration on both SteelHeads and restarting the optimization service, access the secure server from the web browser. These events take place in a successful optimization:
– If you specified a self-signed proxy certificate for the server on the server-side SteelHead, a pop-up window appears on the web browser. View the certificate details to ensure that it’s the same as the certificate on the server-side SteelHead.
– In the Management Console, the Current Connections report lists the new connection as optimized without a red protocol error.
– In the Management Console, the Traffic Summary report displays encrypted traffic (typically, HTTPS).
– Verify that the back-end server IP appears in the SSL Discovered Server Table (Optimizable) in the SSL Main Settings page.
Note: Because all the SSL handshake operations are processed by the server-side SteelHead, all the SSL statistics are reported on the server-side SteelHead. No SSL statistics are reported on the client-side SteelHead.
• Monitoring SSL Connections - Use these tools to verify SSL optimization and to monitor SSL progress:
– On the client web browser, click the Lock icon to obtain certificate details. The certificate must match the proxy certificate installed on server-side SteelHead.
– In the Current Connections report, verify the destination IP address, port 443, the Connection Count as Established (three yellow arrows on the left side of the table), SDR Enabled (three cascading yellow squares on the right side of the table), and that there’s no Protocol Error (a red triangle on the right side of the table).
– In the SSL Statistics report (on the server-side SteelHead only) look for connection requests (established and failed connections), connection establishment rate, and concurrent connections.
• Monitoring Secure Inner Channel Connections - Use these tools to verify that secure inner channels are in use for the selected application traffic types:
– In the Current Connections report, look for the Lock icon and three yellow arrows, which indicate the connection is encrypted and optimized. If the Lock icon is not visible or is dimmed, click the magnifying glass to view a failure reason that explains why the SteelHead is not using the secure inner channel to encrypt the connection. If there’s a red protocol error, click the magnifying glass to view the reason for the error.
– Search the client-side and server-side SteelHead logs for ERR and WARN.
– Check that both SteelHeads appear in the white peering trust list on the client-side and server-side SteelHeads, indicating that they trust each other.
For details about the secure inner channel, see
Secure Inner Channel Overview.
• SSL Issues with Internet Explorer 6 and Oracle R12 - Previously, RiOS fixed a vulnerability found in CBC-based ciphers prior to versions 0.9.6e by inserting an empty frame on the wire to avoid a Chosen Plaintext Attack on cipher-block chaining (CBC) ciphers. Some versions of client and server applications do not understand the insertion of empty frames into the encrypted stream and close the connection when they detect these frames. Therefore, RiOS no longer inserts empty frames by default. Examples of applications that close the connection when they detect these empty frames are IE6 and Oracle R12. SharePoint under IIS has also exhibited this behavior.
The failure occurs when the SSL application fails to understand the data payload when either the client or server is using a block cipher using CBC mode as the chosen cipher. This failure can be with DES, AES, or 3DES using CBC. Note that when SteelHeads are deployed, the chosen cipher can be different than when the client is negotiating directly with the SSL server.
Note: Because current web browsers do not protect themselves from this vulnerability, SteelHeads are no less secure than other vendor’s appliances. From a security perspective, fixing this vulnerability is the responsibility of a server, not a patched client.
To determine whether the SteelHeads are inserting empty frames to avoid an attack, capture TCP dumps on the server-side SteelHead LAN interface and look at the Server Hello message that displays the selected cipher. Verify that DES, AES, or 3DES is the cipher. Also, check for the existence of 32-byte length SSL application data (this is the empty frame) on the LAN traces, followed by an SSL Alert.
To change the default and insert empty frames, enter the CLI command no protocol ssl bug-work-around dnt-insrt-empty.