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."
Microsoft's ISA (Internet Security and Acceleration) Server has been providing functionality to accomplish just this (reverse proxy publishing of web servers, acting as the SSL endpoint, passing on unencrypted or re-ssl'd traffic to the webserver post-inspection of the http traffic) for quite some time.
/sharepoint, your /cacti, your /owa, and your /intranet sites) using path rules on the same IP address - one point of entry (or multiple points, with an array of ISA boxes), with a collection of disparate apps in your WAN / DMZ behind it.
Not only does it work very well for microsoft and non-microsoft webservers (and perform application-layer inspection of a number of other protocols), but neither ISA 2004 nor ISA 2006 has had a single exploit in the wild (Don't believe me? Check secunia.com). ISA also sits in between most of the higher layers of the windows networking stack and the network itself.
ISA even supports pre-authentication for sites published like this - ISA 2006 even extends form-based auth (with cookies) to this for sites other than Outlook Web Access (Exchange's webmail interface). It'll also publish multiple sites (say, your
As an aside, mod_security plus the reverse proxy capability in Apache 2 does precisely this too - with a little webmin love, a reverse proxy SSL offloading / inline web inspection linux distribution based on a very lightweight version of debian or redhat would be extremely easy - has anyone done anything prepackaged already, or thought about doing such?
The protocol is not insecure; In order to enable the proxy to decrypt the SSL session, one of the endpoints must cooperate. It could work the same way with any of the protocols you mention.
Firebug. It will make your jaw hit the floor.
If they were able to do this without cooperation of the endpoints, it'd be a man-in-the-middle attack, and yes it would demonstrate that SSL is insecure.
The article's background information skips over an important point: the WAN accelerator device must be owned by the same group that runs the server. So this is for your data centers, not for your corporate headquarters.
I've never heard of this sort of device before, but I'll give my own background, filling in the gaps from their later information, my understanding of SSL, and a couple guesses.
The original (unencrypted) problem: Say you have a low-bandwidth link between a bunch of servers and clients. You want to make the best use of your link's limited bandwidth through compression (as well as QoS and such). In fact, you want to say "these next 426 bytes are the same as chunk 12345, which I've previously sent to some other client". The original setup looks like this:
The solution: obviously you can't say "just access chunk 12345" to client B if you sent chunk 12345 to client A. That's why they use a pair of these devices straddling the slow link to do this compression. They compress when sending and decompress when receiving. In the end, you still need to be able to send all the original bytes to each client. You might have many slow connections, but we'll say it's a "fast" link because in aggregate they're fast enough. So the setup looks like this:
Now, I'm not sure how common this setup actually is. Apparently you've cheaped out and gotten a T-1 or something across town, but you still have to pay for all the upstream bandwidth as the data leave your control or diverge. But let's just go with it.
Now add encryption. You could look for commonalities in the encrypted streams, but you're unlikely to find much. For the compression to be effective, it needs to work on unencrypted data. And you can't just forge a certificate on-the-fly to make proxying transparent, unless you've found a man-in-the-middle vulnerability in the SSL setup. Short of that, this is possible under one of two conditions: (1) the validators trust a CA certificate to which the device has a private key, so it can issue new certificates on the fly, or (2) the device has been preloaded with keys for every certificate it is expected to proxy.
The choice they've made seems to be this: you're assumed to control the servers but not the clients. So if you want to have an SSL connection to a given server, you need to load that server's key somewhere onto this pair of devices. (Preferably the Accelerator.Server for security.) That's what they're talking about in this paragraph:
I'm not sure if they support SSL client authentication, but if they did, the choice is the same: load all the clients' keys onto the device or have your servers trust the device's CA.
It is a MITM. But I hate burst your bubble, but the majority of large ecommerce presences terminate SSL at hardware level appliances(SSL offloaders) and usually don't reencrypt it to the server.
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!
I've actually been around SSL Accelerators for a few years now, working in the web hosting industry. The idea is pretty much the same; your customers connect to your website using https, except they're actually talking to an SSL Accelerator/load balancer device, not the actual web server. The SSL Accelerator holds the SSL certificate, decrypts the traffic, and sends it to the web server in plain text. The web server replies back in plain text, the SSL Accelerator encrypts it, and send it back to the customer's web browser. Being a device made specifically to handle this type of traffic, the SSL Accelerator can encrypt/decrypt a lot faster than the web server, leaving the web server to do it's task of serving up content without all the overhead involved with SSL.
Normally, the SSL Accelerators are in very close proximity to the web servers (both network and physical distance-wise). The thought of doing something similar with enterprise WAN traffic over long distances, however, is a bit more frightening. I guess like many other things out there, it all depends on who your vendors are and how you implement the solution. Just be careful.. the Internet can be a nasty place.
Don Head
UNIX/Linux Administrator