See your link here
SSL offloading / accelerating / load-balancing is scary
7 comments- IT TOPICS:Business Intelligence, Emerging Technology, Internet, Management, Networking, Security
I have been taking some training recently on web accelerators, WAN optimization, proxies, and other security devices, and one of the trends I have been noticing is the increase in devices that can decrypt SSL traffic for scanning and acceleration. This really has me concerned for a few reasons.
One is the privacy issue. There are a few devices that are performing scanning of traffic at the ingress point of the network, and they have the ability (basically through session-hijacking) to decrypt and scan incoming SSL traffic. While I see the security reasons behind scanning SSL traffic (it is fairly easy for bad guys to hide what they are doing via SSL), I also see a HUGE privacy concern for users. What if there is some personal data being decrypted? What about credit card numbers? While the vendor showed me how these concerns could be reduced (by different policies that stop certain traffic from being decrypted), it still has me worried about abuse by some disgruntled or just plain evil IT guy.
Second is the issue of a very tempting hacking target for the baddies out there. If this thing is decrypting traffic, it makes sense that the bad guys would want to see what it is decrypting. Also, many of these devices do SSL offloading for web farms. Basically, they do the decryption and encryption of the traffic to take the load off of the servers on the farm. Good idea. But it also means that the device has the keys to the kingdom. While it is arguably easier to lock down a device than a server, it still gives the bad guy a target to focus on (some use these devices for decrypting traffic to make load-balancing decisions, then they re-encrypt and send it to the server - either way, the problems are the same).
And tonight, as I was browsing through my info-junkie list on Blogbridge, I came across this post, and I saw some of the same concerns I have had. Let's look at this quote:
There are a number of weaknesses in this design beyond the obvious one that the data is in the clear while being processed by the SSL appliance. If you keep your private key in an HSM [hardware service module], you’ve just downgraded its security to “stored in flash and RAM of a front-end network device.” Also, now there are two places to compromise the key. Even if both offered equal security but different implementations (i.e., different bugs), you’ve reduced the private key’s security by 50% because an attacker can choose between the two targets based on their bag of exploits.
This is a fantastic point. Not only have you given the attacker another place to focus, you have also given him MORE choices for his attack. That is not a good thing. And another issue the author brought up to one commenter was that it is likely that the device is using proprietary (A.K.A. non-tested) methods, hence less secure. He said made his point sarcastically by saying this:
...because no appliances use OpenSSL like the server does. And appliances that use a home-grown implementation are less likely to have flaws than a publicly-reviewed codebase that is 10x older and used in 1000x more systems.
One point I want to make on these devices is that they are quite often being adopted by the network team. If the company does it right, the security team is going to have to sign off on this puppy. But that is too often not the case, and this is a huge concern because these devices can go in without a true test of their claims of being secure. I am not saying network people are stupid. I am saying that their main concern is not usually security (though everyone should be concerned with security first, but I digress).
So basically, I have always been a little wary of these technologies, even if they are supposedly locked down and the vendor gives me ten thousand promises that they are encrypted with AES. But it also a reality that these devices are being adopted, so the security gurus need to be testing these things to make sure the promises made are promises kept. The first time someone's ID gets jacked because one of these devices has a crack in it, someone is going to pay.
Print
Email this
Digg this
