Problem solve Get help with specific problems with your technologies, process and projects.

Three SSL acceleration questions answered

SSL acceleration requires making changes to traditional WAN optimization tools so that they can read through encryption.

1. Why do we need acceleration tools for HTTPS and other encrypted traffic?

WAN optimizers excel in compressing and deduplicating plaintext data streams, but they must be specifically configured...

to handle Secure Sockets Layer acceleration.

With plaintext data streams, such as HTTP or Telnet, the payload inside the packets can be read by the human eye, a protocol analyzer like Wireshark or a WAN optimization tool. But for privacy and security reasons, most unencrypted protocols have an encrypted alternative. Folks that once used Telnet have moved over to Secure Shell (SSH), and many banking customers insist on an HTTPS connection instead of HTTP. Because these protocols are encrypted, traffic is no longer easily readable to a protocol analyzer or WAN optimization tool without the proper decryption keys.

Typically, WAN optimizers parse protocol streams and extract their payloads using compression and deduplication to optimize the payload. Other optimization techniques are then applied to the overall conversation to hasten the optimized payload's journey across the WAN.

Out of the box, WAN optimizers don't have the keys to read encrypted payloads. If the appliance can't read the payload, the encrypted data will flow through a WAN optimizer unchanged, and optimization techniques are limited to the transport layer.

2. How can a WAN optimization appliance accelerate SSL traffic?

The key to accelerating SSL traffic is the key. The same certificate and key pair that is installed on your Web server is installed into your WAN optimization infrastructure. Using Riverbed's Steelhead as an example, here is how SSL acceleration for HTTPS traffic happens using server certificates:

  • The certificate and private key are installed on the Steelhead closest to the HTTPS server (the "server-side" Steelhead).
  • The client opens an SSL connection to the server.
  • The server-side Steelhead establishes the SSL session with the client and provides the client-side Steelhead with information about the session. This allows the client-side Steelhead to handle the SSL session with the client going forward, but without requiring that it have the private certificate and key stored locally.
  • With the SSL session established, the actual encrypted HTTP conversation can now proceed between client and server through the WAN optimization appliances.
  • Encrypted client traffic arrives at the client-side Steelhead where it is decrypted. The decrypted traffic stream is then optimized with all of the same HTTP protocol optimizations available to unencrypted HTTP traffic.
  • The original traffic stream was encrypted for a reason, and so before the optimized traffic can be transferred across the WAN, it must be re-encrypted. The Steelheads use a special SSL "inner channel" to securely carry optimized SSL traffic between the client-side and server-side Steelheads.
  • Finally, the optimized data stream arrives at the server-side Steelhead where it is decrypted, normalized, re-encrypted and transmitted to the server.

In summary, SSL traffic is encrypted, decrypted, optimized, re-encrypted, decrypted, normalized, re-encrypted and finally delivered. Got it? OK!

3. What other factors should you consider when deploying SSL acceleration?

  • You must install and maintain the certificates and keys on at least some of the WAN optimization appliances in your infrastructure. When certificates expire, it won't be enough to update the certificate on the server. You'll need to update the certificate on one or more of your WAN optimization appliances as well.
  • Depending on your certificate vendor, you'll likely need to install intermediate certificates in addition to the server certificate to form a complete certificate chain of authority. While the most common intermediate certificates will probably already be pre-installed in your WAN optimization appliances' certificate store, others will not.
  • If your organization has a physical security policy for devices housing certificates, you'll need to bring your server-side WAN optimization appliance into compliance with this policy. And even if there is no explicit policy to consider, it is a best practice to ensure that devices storing certificates are physically secured. On the plus side, physical security requirements do not change in your branch offices for a Riverbed shop, as the remote WAN acceleration appliances do not store the certificates or keys.
  • You'll need to monitor how effectively your appliance is optimizing your HTTPS connections, just as you should be monitoring HTTP connections. Riverbed Steelheads have an HTTP auto-tuning algorithm that determines what optimization will be applied to a given HTTP session. This tuning may or may not be ideal for your application, and should be reviewed to ensure that your application is being optimized for WAN traversal as completely as possible without compromising application behavior.

You invested a lot of money into your WAN infrastructure and branch office connectivity. Adding SSL acceleration to your technology arsenal is an excellent step in making the most of that investment. But it's important not to overlook encrypted traffic acceleration when reviewing your WAN optimization needs.

Don't forget that HTTPS isn't the only sort of encrypted traffic that can be optimized. Other common encrypted protocols like Server Message Block (SMB), Simple Mail Transfer Protocol (SMTP/TLS) and Messaging Application Programming Interface (MAPI) are among the encrypted traffic types that can be optimized to improve your WAN's overall performance.

More on traffic acceleration and optimization

This was last published in October 2012

Dig Deeper on Network application performance