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."
The cited analyst is confusing proxying conducted by someone the site designates vs. yourself. One doesn't let anyone do anything they can't already. The other means you have all your confidential information sitting on a device that is not engineered for efficency.
Inventions have long since reached their limit, and I see no hope for further development.-- Frontinus, 1st cent. AD
What about Akamai's SSL encryption? http://www.akamai.com?
the general public complain about options that backhaul ISP providers use to help reduce their expenses, increase performance and keep costs down as much as possible. Backhaul of circuits in remote sites with Sat bandwidth is enormously expensive. With new bandwidth intensive applications coming out all of the time, an ISP can either optimize their traffic to support the new apps, or pass the increase of their upgrades on to their users and then listen to the users whine about the new cost. The internet was never and should never be considered a replacement for a private WAN if data security is of the utmost importance for your business. Does it work - yes. Is it a replacement - no. ISPs are not in business to provide non-profit service to corporations who choose to use a cheaper method of transporting their private data and then listen to the complaints about such matters. If you consider your ISP to be doing something disreputable with your encrypted traffic - find another ISP or switch to a private WAN circuit.
Honestly, I can't say I give a shit about this. But I run a small-potatoes operation, rather quite out of the league of the big boys and their network appliances.
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?
Um... Isn't that the very definition of a man-in-the-middle attack?
Er, no. Thank you very much for your kind offer, but I would prefer my encrypted data were not "optimized" in this way.
Schwab
Editor, A1-AAA AmeriCaptions
"some WAN optimization gear can terminate the SSL sessions, shrink the traffic and re-encrypt it for the next leg of the trip."
Doesn't this completely defeat the point of SSL? An encrypted link from client to server? If you got to an SSL website through this WAN link, it's not going to be encrypted anymore unless you trust the keys from the WAN access point. So, unless each WAN has it's own trusted key through a signature authority this isn't going to work. Seems pretty stupid to me. Isn't SSL traffic already compressed as part of the encryption procedure like PGP does?
SSL adds 200ms latency as compared to not using any encryption.
Is there a way to reduce the SSL latency?
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.
Its a good thing that these devices can offer SSL, but it should only be talked about as "additional" security measures. There seems to be a trend in the IT world where one "new" security tool comes along and renders some "other" (other, not older) security tool/method discarded. These lessons have been learned, and shouldnt be repeated: Defense in Depth.
20th century Marxism is not progress...
True, but in VPN and SSH no endpoint will usually cooperate. With SSL this seems to be assumed as something that should be allowed, and possibly without telling the user. Bad, bad design IMO and a fundamental flaw.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Sure they if they are configured to do so. It;s not that hard and has been productied for years.
Nothing new, let's move along.
Any administrator who puts in a security hole like that to get a minor reduction in bandwidth is grossly irresponsible. No device in the middle of the network should have the end to end decryption keys. Ever.
If you have too much traffic to your secure servers, take a look at what they're sending. Maybe the canned images can be moved to a non-secure server, where they can be cached locally. You're probably not actually sending huge volumes of secure data to a browser.
Or maybe you just need to find out who's downloading videos and stop them.
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.
As I recall it's criminal to intercept financial communications without permission from the institution.
That means, if an employee at a company that uses a BlueCoat device were to say login to a bank... the sysadmin would technically be violating the law.... unless the bank gave explicit permission (most likely would need to be in writing).
Even if you were to ban online banking in the workplace, that wouldn't change the impact on the sysadmin's libility if a user broke the rules. Go ahead, fire the employee... they just let the bank know about the security breach, and who the "hacker" was.
Seems to me like the laws may need some adjusting.
And that's why I don't login to a bank from work. I know sysadmins in many companies steal SSN's, credit card #'s, etc. by using Timbuktu, VNC, etc. as well as sniffing packets. It's just what it is. Why should I put my identity at risk? I don't see a good reason. I wait until I'm home for that. It's one thing to read an email, it's another to jack by SSN.
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!
It'll also publish multiple sites (say, your /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
In other words, something Apache has done for more than half a decade?
Please help metamoderate.
Yes, but that cooperation may not be the result of informed consent. It's painfully easy for an untrusted application to stick a new root CA into IE's list, after which it can sign its own certificates and use them to intercept SSL. MarketScore, reportedly, did this.
net-to-net VPN is what any sane person would use for a WAN
You have a good point. Also, organizations that pre-load their own root certs on their computers get the power to intercept SSL connections made from those computers. I never really thought about it before, but that means if I'm doing online banking at work, the IT department could read it all. Theoretically.
Firebug. It will make your jaw hit the floor.
I don't understand why this is being portrayed as something "new" to IT. I work for a medium sized company, and we have been doing this for nearly 5 years. There are a slew of vendors in this space including F5 Networks, Citrix, Sun, and Microsoft. The technology works be installing the SSL certificate onto the appliance rather than the server. If designed correctly, this is no less secure than the conventional model, and can save significant processing load on web servers.
Todd Gardner
There are really no foolproof solutions; SSL's users can't judge the authenticity of certificates so asking them to verify anything isn't an option. Usable yet bulletproof security is still an unreachable holy grail. But I'd like to point out that you can still trust your SSL connection to Amazon as long as you really do trust all the people with certs in your trusted root list.
And I'd also like to point out that unless you manually verify the SSH keys using a seperate secure channel during your first connection to a host, SSH is vulnerable to attack at that time. Sure, SSH tells you you're insecure, but when you ignore it that doesn't help anything. And I'll wager *very* few people actually check their SSH keys properly.
SSL enables you to securely connect to anyone with a cert you trust on a moment's notice without a separate secure channel to enable key exchange; SSH doesn't replace that and neither do VPNs.
Firebug. It will make your jaw hit the floor.
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
Yes, but this would be illegal (which might not stop them). Companies may have the right to monitor all traffic on their networks, read email, etc. They also certainly have the right to block all traffic to your bank. But for them to read your online banking transactions it would require them to forge your banks SSL certificate (i.e. they would need to create a certificate that claims it belongs to your bank, but they would sign it with the companies pre-loaded root cert). IANAL, but I'm fairly certain that would constitute fraud and would be actionable.
Depends on who you choose as a vendor, how your org is using the technology and where in the network you implement the protocol/system. cisco is too easy to hack (Cisco security is too common and based on shitty code), but juniper and a few others have pretty good products in this space. The bottom line is- if it is plugged in, it is vunerable. Its really all about making it too difficult for some wannabe high school black hat to access sensitive data. SSL is great for remote workers (ie sales and such), as long as the system used is ASIC based or has the processing power to handle the encrypt/decrypt. From a administration perspective it is a godsend as there are no clients to load, patch and monitor. As this technology has been out for a few years, I am sure there are emerging technologies to replace this, but from a users perspective (and from most IT Dir's POV) this alleviates a great deal of complexity for non-power users and at the same time makes remote access easier to manage.
As a sales guy (former network eng), I find it amazing how many people have the wrong perception and are unwilling to listen to others. Black, grey and white hat-it is easy to tell IMMEDIATELY who knows their shit and who just talks it, just like the guy I just sold a GBIC to for his Avian over IP layer 3 switch.
The whole point of these devices is that *don't* need to forge the bank's SSL certificate - they're breaking the end to end nature of SSL and inserting a proxy inbetween that allows the admins to get at the banking data in plaintext.
You have no way of verifying it because the ability to verify the SSL certificate is taken away from you (every site returns the certificate of the proxy).
Yes reading such data would be actionable - as would reading most emails without explicit written consent. Hasn't stopped them in the past and won't stop them in the future. If you *really* trust those admins then go ahead and use SSL sites at work, otherwise don't bother because it's not secure anymore.
The concept is just awesome. Please read the mechanisms and search ssl wan acceleration and do research. great work by some of these companies
Anyone have familiarity or an opinion on with working with Kemper Technologies' LoadMaster devices for this? http://www.kemptechnologies.com/load-balancer-1500 .shtml Looking to do incorporate something like this for my site, but to fork over 4g to nCipher for a replacement NIC seems a bit nuts for a non-commerce app.
to keep your connection security.
If you not trust SSL, how you keep security trade through SSL?
Areas of concern that SSL addresses: 1. Unauthorised access to cached data at each access point Problems that SSL poses: 1. Slower throughput due to encryption process