How to Solve Performance Issues with SSL Encrypted Traffic

With the security concerns we face these days it’s ever so important for organizations to use encryption to secure their data in transit. And since the HTTP protocol is so widely used as a means to transfer various types of data, like MAPI over HTTP, a mechanism is needed to secure it. That mechanism is SSL or TLS. There are several reasons you might experience performance issues when using HTTPS sessions between two hosts. In this article, I’ll show you how to address these performance issues using Riverbed SteelHead technology and SSL optimization. Before getting into the nuts and bolts of SteelHead, let’s talk briefly about SSL. This will aid in understanding the configuration requirements once we get to that point.

SSL Overview

SSL, or really TLS these days, uses both symmetric and asymmetric encryption. Symmetric encryption is commonly used for real-time data transfer. The keying is smaller than that of asymmetric encryption and the same key is used for both encryption and decryption. Asymmetric encryption uses two keys, a public key and a private key. A sender uses the recipient’s public key to encode and send a message; the recipient uses its private key to decode the message and within this communication, a symmetric session key is calculated. Asymmetric encryption isn’t often used for real-time data as the key size is much larger, often 2048 or 4096 bit. As mentioned, asymmetric encryption is used to send a message that we then calculate the symmetric key with. The symmetric key is random and is only used for the current conversation. This key is known as the session key. Once the session key is established both parties encrypt and decrypt using the session key.

For a moment, let’s look at the SSL negotiation process.

SSL Process

As you can see in the figure, the process begins with a client sending a hello to the server. In response to this, the server sends its public key. The client then sends the random material that will be used to create the session key. The server’s public key is used for this and the data can only be decrypted by the server using its private key. The server generates keys and responds back to the client with the “Change Cipher Spec” message, switching further communication to the use of the generated session keys.

So, now that we’ve reviewed the SSL process, let’s talk about what we need to do to configure our SteelHead environment to optimize SSL traffic. I do want to note here that we can certainly optimize ALL SSL traffic since really it’s just a TCP session. But what we really want to get at is the different types of traffic inside there so we can perform additional optimization techniques as needed.

Optimization of SSL

So here’s how the overall process of SSL optimization works:

1. Server-side SSL Certificates and Private Keys are copied to the SteelHead appliances.
2. The SteelHead appliances use their own identity certificates to establish a secure connection between one another proactively or on-demand.
3. When the client sends the initial “hello,” it is intercepted by the server-side SteelHead appliance.
4. The server-side SteelHead establishes a connection with the server.
5. The server-side SteelHead then establishes an SSL connection with the client. This comes in the form of the server-hello.
6. A temporary session key is migrated from the server-side SteelHead to the client-side SteelHead. This moves the SSL session between the client and the client-side SteelHead.
7. Transfers over the WAN are now accelerated and optimized between the client-side SteelHead and the server-side SteelHead using all of the Riverbed RiOS mechanisms.

For all this to happen, there must be a trust between the two SteelHeads. The client must trust the server-side SteelHead and the server-side SteelHead must trust the certificate it receives from the server.

So let’s configure SSL optimization. I’ll take you through each step, but I also recommend you watch the video where I walk through each of these steps.

To begin, here is the topology I’ll be using in this configuration.

SSL Optimization Topology

Our first step is to obtain and install SSL licenses on the client and server. The license if free and should be included. You can verify that you have it by navigating to Maintenence>License. You can see what you’re looking for in the image below. You’re going to want to make sure that both the client- and server-side SteelHeads have the license. If not, you’ll need to contact Riverbed Support.

Verify License

Your next step is to enable SSL optimization on both SteelHeads. You’ll find this checkbox in the SSL Main Settings. When you enable SSL optimization you must save and restart services on the SteelHead.

Enable SSL

Now, recall that the server-side SteelHead intercepts the initial request from the client and it’s the server-side SteelHead that then creates its own SSL session to the server. The server-side SteelHead then uses the server’s private key and certificate to then create a session with the client. In other words, the server-side SteelHead responds to the client’s SSL request to the server, as if it were the server. For this reason, you need to get the server’s certificate and private key on the server-side SteelHead. You also need the CA certificate so that you read and trust the imported server certificate. First import the CA certificate under SSL>Certificates.

CA Certificate Import

Then, import the server’s key and certificate back in SSL>Main Settings. Import both the key and the certificate.

Import Server Cert and Key

Now, on the client-side SteelHead create an in-path rule to allow optimization of the desired SSL servers. In the image below, I am looking for ANY IPv4 traffic headed specifically to the server. Also, make sure this rule is added above the default rules or it won’t be matched and the traffic will bypass optimization and be passed through.

In-Path Rule for SSL

At this point, you can send traffic. When you do this, you’re going to notice that traffic will be matched and it will have some of the RiOS techniques applied to it. But also notice the red triangle in the image below. What’s that all about?

SSL No Peer

By expanding to see the details, you will note that the inner channel is not secure. Why not? Well, the client-side and server-side SteelHead don’t trust each other now. By navigating to SSL>Secure Peering(SSL) you’ll find an entry on the gray list. Use the Actions drop-down to move the SteelHead to the white list by selecting Trust.

White List Peer

Once the peering is established, we can try a download again and we’ll see that everything is in order and that all of the power of the RiOS Optimization techniques are now able to be applied to SSL traffic.

SSL Optimized

Wrap Up

Well in this short post we’ve covered the need for SSL optimization as well as an overview of how SSL works and how to configure both the client-side and server-side SteelHeads to handle the optimization of this traffic. By giving attention to these types of technical aspects in an enterprise network, we can enhance the user’s experience by eliminating many of the common performance issues they experience. SSL optimization is just one of many capabilities in the Riverbed WAN Optimization arsenal. Head on over to the WAN Optimization solutions page and learn more about what Riverbed can do for your organization.