When accelerating secure traffic is not secure

SSL (Secure Sockets Layer) has become one of the most widely-used security protocols on the Internet.  SSL used just about everywhere, on the Public Internet as well as in the internal enterprise network.  You can use it for a variety of purposes, from purchasing merchandise on amazon.com, to accessing files securely from your sharepoint server, as well to access your enterprise applications such as Oracle Forms, SAP, Siebel, etc...  Ensuring that the SSL-encrypted data sent over the network stays secure is extremely important, as it may contain vitally-sensitive information such as credit card numbers, proprietary corporate data, and personal employee information.

Riverbed offers the ability to securely accelerate encrypted SSL traffic. Riverbed's approach has been analyzed and validated by ICSA Labs as being secure.  On the other hand a few other WDS solutions also claim the ability to intercept and accelerate SSL traffic.  But while the vendor may claim their approach is secure, a closer examination reveals that their SSL acceleration solutions introduce serious security vulnerabilities.

A secure WDS device is paramount, because for WAN optimzation, an appliance needs to be deployed in the branch office as well as in the data center.  In contrast to the 24x7 security that exists in your physically locked data center, in a small branch office the security situation may be far more suspect.  There may be no employees present after work hours.  Holidays, weekday nights, and weekends are periods where an intruder can gain access to the facility.  A typical enterprise with tens or hundreds of branch offices cannot ensure that all of them will be physically secure during these down times.

How can you tell if a WDS solution is secure, and is capable of optimizing SSL traffic without compromising security?  In this blog I have outlined a two key vulnerabilities to look for in competitive WDS solutions.

The first vulnerability is the more obvious one:  Does the WDS solution support a disk encryption capability?  Amazingly, several of the WDS vendors offering SSL optimization capability cannot encrypt data stored in their disk drives.  When using these solutions, data that was formerly encrypted by the web browser for the SSL-protected WAN transfer is stored in clear-text format in the hard drives of the WAN optimization appliances.  In other words, credit card numbers, proprietary drawings, and any other confidential information that employees incorrectly thought was securely encrypted and protected, is actually stored and exposed in clear-text format on the WAN optimization device's hard drives.

And then to top it off, these WDS vendors offer hot-swappable hard drives for their un-encrypted disks.  This makes it very easy for the intruder--they don't even have to open up the chassis to gain access to the sensitive data.  In the remote branch office over the weekend, or anytime when few employees are around, they can just walk by, pop the disks out, and then quietly slip away.

The second vulnerability is a bit more technical, and requires somewhat of a security background to understand and appreciate.  It has to do with the root Certificate Authority (CA).  The Certificate Authority is the entity responsible for validating the authenticity of a given web server.  The SSL protocol uses the CA to make sure that the server you are accessing is really who they claim to be.  Once a web browser installs and acknowledges a CA as being authoritative, then the web browser will implicitly trust anything that CA tells it regarding the identity of any web server.  The CA is a critical entity, and its compromise allows an attacker to substitute their own web servers to masquerade as yours.  As the CA is a critical part of your security infrastructure, it should be only be hosted in a physically-secure, protected facility.

But the problem with at least one WDS solution offered by a Riverbed competitor is that to accelerate SSL, this solution requires that the vendor's own proprietary CA be recognized and accepted as a new Certificate Authority by employee web browsers.  That normally wouldn't be a problem if the CA is hosted in a physically-secure, protected facility such as an air-conditioned data center.  However, this vendor's WDS solution requires that the CA be hosted in the remote branch office when WAN optimization functionality for SSL is used.  The possibility of an intruder gaining access to the branch office-hosted CA's private keys would raise alarms with any competent security expert.

One of the WDS solutions marketed by a Riverbed competitor has both of the security vulnerabilities I described above.  Ironically, the vendor offering that solution is considered a "security" vendor....can you figure out who that vendor is?

Josh Tseng

Comments

[wanuser]

The whole point in my mind of SSL is end to end security from Browser to server. Why would I possibly want to allow a 3rd party regardless of certification to break that security

[Josh Tseng]

Wanuser,

The Riverbed solution accelerates SSL traffic while preserving end-to-end security. Unlike some competitive products, Riverbed supports encryption of disk-resident data through strong encryption algorithms (128-bit, 192-bit, or 256-bit AES).

As far as allowing any 3rd-party to interact with your SSL sessions, you may be aware that there are plenty of application front-end devices used to load-balance SSL sessions and offload SSL crypto processing from the web server. F5's BigIP and Cisco ACE are two examples of such products, but there are many others and they are in widespread use today. When you do your shopping on public Internet web sites, you are more than likely connecting through one of these products with your secure SSL sessions. Most experts agree that these devices do not increase security risk, even though they are a 3rd-party device involved in your end-to-end client-server SSL sessions.

Using Riverbed to accelerate SSL traffic is not much different. As with these commonly-used application front end devices, private keys and certificates remain strictly in the data center. There is no change to the security trust model, but Riverbed is able to address WAN-related performance issues such as latency and bandwidth, in order to deliver 20X to 40X faster performance.

BTW, is anyone able to identify the "security" vendor who lacks a disk encryption capability to protect the confidential data that they cache on disk when optimizing SSL sessions? Hint: this vendor's tag line is "Stop the bad. Accelerate the good."

Josh Tseng

[rvbd_usr]

We all know Bluecoat does not have disk encryption as a matter of fact If I recall Riverbed themselves did not offer disk encryption until very recently.

[Josh Tseng]

Riverbed introduced disk encryption in RiOS 4.1, almost one year ago (October 2007).

Furthermore, Riverbed never had an "Object Cache" as Blue Coat does. The "Object Cache" does not obfuscate data in any way as Riverbed's SDR does, which "shreds" the data up into ~100 byte chunks.

Josh Tseng

[WDS_geek]

What about client certificates? Does Riverbed support those? Also, what is the key material that the client sees when establishing the session to this purported server? Is it key material from the server itself, or something the Steelhead generates? What symmetric key and public key algorithms does the Steelhead support? How does the Steelhead handle certificate revocation, i.e. beyond standard certificate expiration? How does the Steelhead handle situations where SSL traffic is tunneled transparently over a simple HTTP connection from a client to a web proxy? Where are the keys stored that are used for encrypting Steelhead disks, and how is the key material for the secure vault managed and protected?

[Josh Tseng]

Dear WDS_geek,

I have answered these questions for Riverbed customers, and would be happy to answer them for you offline if you identify yourself. However, I cannot do it here as this is a public forum.

Please email me offline at jtseng@riverbed.com and we can continue this discussion.

Best regards,
Josh Tseng

[photoa]

Just out of interest, have you or anyone else actually broken into a Blue Coat system and recovered data directly from disk? We all know (as another poster indicated) that Blue Coat doesn't have disk encryption, but neither have I heard of anyone actually getting private data from the disk.

[Josh Tseng]

That may be a valid question, but I don't think the answer would necessarily be meaningful. As you may know, the worst type of security breach is the one that you're not aware of.

In the past when used as a secure web proxy, Blue Coat devices have mostly been confined to the locked air-conditioned data center where they are safe from tampering. But for WAN optimization, you need devices in both the branch office as well as the data center. Unfortunately, it doesn't seem as though they've considered the security implications of using their products outside of the data center.

Josh Tseng