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."

6 of 70 comments (clear)

  1. What about Akamai? by Anonymous Coward · · Score: 1, Interesting

    What about Akamai's SSL encryption? http://www.akamai.com?

  2. Whiskey Tango Foxtrot? by ewhac · · Score: 4, Interesting

    ...some WAN optimization gear can terminate the SSL sessions, shrink the traffic, and re-encrypt it for the next leg of the trip.

    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

    1. Re:Whiskey Tango Foxtrot? by Anonymous Coward · · Score: 1, Interesting

      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.

      If you manage your network infrastructure devices and servers properly, this is no more risky than simply adding more webservers to your DMZ.

      In fact, it probably makes your infrastructure as a whole more resilient, since your webservers are no longer directly receiving traffic from clients, and data can be sanity checked, screened, etc, before it touches your webservers, reducing your overall attack profile.

      I'm sure glad I don't have you managing my network infrastructure - sounds like you rely just a little too much on your 'jump to conclusions mat'

    2. Re:Whiskey Tango Foxtrot? by Melkman · · Score: 5, Interesting

      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.

  3. Re:huh? by flyingfsck · · Score: 3, Interesting

    It only works if your user name is Administrator and your password is 123... ;) This kind of proxy equipment needs the end points to co-operate. It cannot be done on just any ssh or stunnel connection. I don't really see the use for it. If your SSL connection is slow, then you have to adjust the cypher or something.

    --
    Excuse me, but please get off my Pennisetum Clandestinum, eh!
  4. Legality by digitalgimpus · · Score: 2, Interesting

    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.