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 v4.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:

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 v7.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 v7.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 v8.6 and later supports TLS versions v1.0, v1.1, and v1.2. Note that the SteelHead can negotiate to earlier versions of TLS if the peer SteelHead uses a RiOS release prior to v8.6.

Select server name indication (SNI) on the server-side SteelHead while using name-based virtual hosts with SSL. SNI is an extension to the SSL protocol. With SNI, the first SSL client hello handshake message sent to the HTTPS server includes the requested virtual hostname to which the client is connecting. Because the server is aware of the hostname, it returns a host-specific security certificate.

Without SNI, an HTTPS server returns a default certificate that satisfies hostnames for all virtual hosts. The SSL connection setup uses the default virtual host configuration for the address where the connection was received. Browser messages warn that certificates have the wrong hostname. With SNI enabled, RiOS provides the hostname. This enables the server to determine the correct named virtual host for the request and to set up the connection accordingly from the start.

The browser validates the certificate names against the requested URL, and the server-side SteelHead verifies that the selected proxy certificate is compatible with the client hostname. This ensures that the browser does not reject the proxy certificate for the server-side SteelHead.

If SNI provides a hostname that does not exactly match the common name or any of the subject alternate names for the certificate on the server-side SteelHead, the system determines that a valid certificate is not present and bypasses that hostname. No configuration is necessary on the client-side SteelHead.

The client browser must also support SNI.