Slashdot Mirror
SSL Optimization Over WAN Needs Scrutiny
coondoggie writes with word of the expansion of WAN optimization appliances to handle SSL traffic and the security concerns this brings up. From the article: "With more and more WAN optimization 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 centers, some WAN optimization 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 optimization appliances will become more important to businesses that want to keep traffic secure while minimizing the size of their WAN links."
If you are a network admin SSL traffic is a bitch. Normal web traffic can be scanned for malicious content with ICAP. With SSL traffic you're out of luck. Also a lot of remote access programs tunnel their traffic in an SSL connection over port 443 (cool service LogMeIn, NOT). That means if you allow encrypted web traffic you also allow people on the network to give control over their PC's to external people. I've dealed with both. Some moron downloaded an infected program of an https site, which was luckily caught by the local virus scanner. And some nitwit called the helpdesk of an ASP which took over teir desktop while he was having sensitive data on his screen. After these events we enabled SSL termination on the proxies and feed all SSL traffic to the ICAP scanner and disallow any traffic that doesn't strictly follow HTTP. If someone has traffic that must bypass these rules the can request an exception, usually this concerns shitty java applications.
that was about a year ago. We were already using Bluecoat proxies, formerly known as CacheFlow.
You do realise it's simply not possible for ISPs to screw with SSL traffic? That's the whole point of this.
These products aren't used for Internet connections. They're used for either dedicated WAN links or for VPN links. Say you have an office out in timbucktoo and a head office. You put one of these on/instead of the the gateway router at the head office, and another at the same gateway at the branch (just inside your network) so all your traffic is going through them. (And these devices are designed to help get the best out of that private frame relay link you've got as well as VPNs.)
What do they do? They automatically cache repeated TCP traffic patterns against all traffic sent to and from the head office. (Basically a matched pair - when one end sends a particular packet the pair of devices has seen before, just the reference to that pattern is sent. Yes, they have to keep in synch and all that.)
See what that gets you. Transparent caching of all interal web browsing. FTP downloads. Transparent caching of file share traffic. IMAP traffic. (Imagine if you send the same 100 kb word attachment to every end user. Now imagine it only gets sent once, without any software seeing anything but normal, ordinary, IMAP.) It just recognises patterns in the TCP traffic, not caring what those patters actually represent. (Lower latency too - because that 100 kb word doc comes out of cache rather than across the line.)
Now SSL disables all this. Each SSL session is unique - the data patterns are low entrophy nearly random noise, from the point of view of these devices. The patterns are never repeated, and thus you don't get to cache anything.
You DO have the option, of course, doing a man-in-the-middle-attack, where you decrypt the traffic on the device, subject that to caching, and re-encrypt it once it leaves the other matched device (presumably the WAN-accelerator-to-WAN-accelrator link is also encrypted.).
BUT ISPs cannot do this. To pull off that M-i-t-m, they have two ways: [1] to screw around with your SSL system's root certificates. Corporates can do this, just deploy their own "trusted" CA. Piece of cake. ISPs can't. [2] Have the private keys for the destination server loaded into the device. Again, Corporates can (sometimes). Edge SSL applicance owned by the same organsiation as the end server can. ISPs, again, can't.
These devices are aimed at corporates, where the network and end-points are all owned by the company. Of course, if the wan-accelerator-to-wan-accelerator link isn't encrypted then you have an issue (can you trust the device designers? That's the POINT of this article!) If that fake CA private key got out, you've also got real issues too!