SSL optimisation over the WAN needs scrutiny

With more and more WAN optimisation vendors extending their capabilities to include encrypted traffic, corporate IT executives have a decision to make: Should they trust the security these devices provide?

Rather than passing through SSL sessions between clients and servers located in remote data centres, some WAN optimisation gear can terminate the SSL sessions, shrink the traffic and re-encrypt it for the next leg of the trip. These chains of encrypted sessions introduce potential vulnerabilities that different vendors address in different ways.

SSL traffic represents a growing percentage of total traffic on WAN links, according to Forrester Research. So SSL support in WAN optimisation appliances will become more important to businesses that want to keep traffic secure while minimizing the size of their WAN links.

In a survey last month of 1,300 IT executives by WAN-optimisation vendor Blue Coat Systems, one-third of respondents said that 25% of their WAN traffic is SSL. And of those surveyed, 45% plan to roll out more SSL applications this year.

About a third of all WAN traffic at Richardson Partners Financial Ltd. in Toronto is SSL, says Andrew McKinney, director of technical services for the firm. But if only the urgent business traffic is considered, the percentage is much higher. "For critical business traffic, it's all encrypted," he says. So he uses Blue Coat Systems gear to secure traffic and optimise it for good performance.

But first he got the devices in and grilled the vendor about the security at each point of the proxy chain until he was satisfied it would keep the firm's data safe. "Our big concern was that we would have control of what was being cached," he says. He didn't want sensitive data left on the disk of the Blue Coat appliance.

"We wanted to be sure the data could be flushed as we required but also that it was securely being stored. In the end we were satisfied," McKinney says.

Such devices sit at both ends of WAN links and perform a number of functions that serve to speed up transaction times. These include optimising TCP sessions, enforcing QoS, byte-level pattern matching and protocol optimisation.

Without SSL support, when SSL traffic hits these boxes they are limited to using TCP optimisation and QoS.

SSL support relies on terminating SSL sessions, decrypting the traffic storing segments of the data for future reference and re-encrypting. Later traffic through the devices is compared with these segments. When data being sent matches a segment, the devices send an abbreviated reference rather than the longer complete segment, thereby reducing the amount of traffic that has to cross the wire.

These segments are analogous to paperwork put through a shredder, says Mark Day, chief scientist at Riverbed. "The individual pieces are still intelligible, but total documents are somewhere between difficult and impossible to reconstitute," he says. Customers concerned that these data segments represent a threat can turn off SSL optimisation and pass the traffic through, he says.

Blue Coat doesn't encrypt the stored segments either, arguing that the difficulty of using the data makes it practically inaccessible. "It's not encrypted but you're going to need NSA-level talent to get that information out of the disk," says Chris King, director of strategic marketing for Blue Coat.

Certeon does encrypt on the disk, storing the keys needed to decrypt it on the appliance that sits across from it on the WAN. That way if one box is stolen, the data on the disk is secure.

In any SSL proxying architecture, the server must give up its certificates to at least one other device. In the cases of Blue Coat, Certeon and Riverbed, that device is a WAN optimiser that sits inside the datacentre where it is as physically secure as the server itself. How those certificates are handled varies from vendor to vendor.

Blue Coat creates a session key for its client-side device using the public key of the server that is held by the server-side Blue Coat device. The server-side device uses the private key of the server to decrypt the session key that is used over the WAN.

Riverbed also generates a session key for the remote SSL session and migrates it to its client-side machine in two steps. Certeon proxies between the server and its server-side appliance, then transmits traffic across the WAN via an IPSec connection. The client side Certeon box creates a separate session to the client machine.

The fact that SSL sessions are being proxied shouldn't scare anyone away, says Joe Skorupa, an analyst with Gartner. Akamai, for instance, proxies SSL transactions -- some of them involving e-commerce -- for its customers, he says. "There's precedent for doing it and doing it where significant amounts of money are at risk," Skorupa says, but each potential user has to balance the need for speed and the need for security. "Customers will have different levels of sensitivity about how it's being done."

Copyright 2018 IDG Communications. ABN 14 001 592 650. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of IDG Communications is prohibited.