Chapter 11 SSL Deployments : Advanced SSL Features
Advanced SSL Features
This section describes the advanced SSL feature set:
  • Client Certificate Support
  • Proxy Server Support
  • Mid-Session SSL Support
    • Client Certificate Support
    Client certificate support enables acceleration 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 accelerating 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:
  • Both the client-side and the server-side SteelHeads must be running RiOS v6.5. or later. If you are running Mobile Controller, you must be running SteelHead Mobile v4.6 or later.
  • Enable client certificate support on the server-side SteelHead.
  • The server-side SteelHead must have access to the exact private key used by the SSL server.
  • You must configure the SSL server to ask for client certificates.
  • The SteelHead must have a compatible cipher chosen by the server.
  • SSL sessions that reuse previous sessions that are unknown to the SteelHead cannot be decrypted.
  • Client-side certificates with renegotiation handshakes are not supported.
  • Client-side certificate supports the RSA key exchange only. It does not support the Diffie-Hellman key exchange.
    • To enable client authentication
    1.
    Perform the basic steps to enable SSL optimization. For details, see Setting Up a Simple SSL Deployment.
    2.
    On the server-side SteelHead, choose Optimization > SSL: Advanced Settings, select Enable Client Certificate Support, and click Apply.
    3.
    Choose Optimization> SSL: SSL Main Settings, import the SSL server private key and certificate, and click Save to save the configuration. You do not need to restart the optimization service.
    4.
    If the client-side is also running SteelHead Mobile, then you must import the Mobile Controller signing CA into the server-side SteelHead. To complete the task, choose Optimization > SSL: Secure Peering (SSL) and select Add a new Mobile Entity in the in the Mobile Trust box.
    Note: Riverbed recommends that you use strong security ciphers, such as AES. Avoid stream ciphers.
    Verification
    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.
    Proxy Server Support
    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.
    Mid-Session SSL Support
    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, see 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.
    Figure 11‑18. Example STARTTLS During SMTP Session
    Source: http://en.wikipedia.org/wiki/STARTTLS (May 3, 2012)
    To enable mid-session SSL support
    1.
    Choose Optimization > SSL: Advanced Settings.
    2.
    Select Enable Midsession SSL.
    3.
    Click Apply.
    Server Name Indication
    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.