One more reason to choose an SSL VPN is that security policies can be very granular. Because SSL VPNs work at the application layer, network administrators can specify access control sets and rules based on such criteria as application, TCP/IP port, and user. That level of control cannot be wrung out of an IPSec VPN without installing additional firewalls behind the tunnel end point and messing with lots of tedious rule sets.
Tunneling Through the Browser
The “client factor” is at the heart of the IPSec vs. SSL debate. When evaluating remote VPN solutions, network managers need to define exactly what applications they want to “webify” for users. For applications that are Web-based, SSL is the clear choice for secure access; most SSL VPN appliances are reverse proxies that easily connect to internal servers. The choice is not so clear when there’s a greater mix of applications, such as Citrix MetaFrame or Microsoft Terminal Services; 5250 or 3270 “green screen” hosts; or X-Windows or other fat client applications.
For non-Web applications, both IPSec and SSL offer workable solutions. The trade-off boils down to IPSec client support vs. SSL proxy configuration. With SSL, this situation exposes a dirty little secret — SSL VPNs aren’t really “clientless.” With the exception of Web traffic, all other application support requires that the browser automatically download and run either an ActiveX or Java applet. For example, Paceck explains, when a user fires up the SSL VPN service from Netilla for the first time, three Java applets download. Normally, this is undetectable.
Just as with IPSec client issues, there can be SSL applet compatibility issues to consider, such as which Java virtual machine has been installed. Running applets may also conflict with browser security settings and require additional client support. Paceck claims, however, that these potential pitfalls have never posed a problem for his users.
SSL is not designed to handle site-to-site VPN situations. When two remote networks connect, all IP traffic should be free to flow between them, which requires connectivity at the network layer, says Dave Roberts, co-founder of security appliance vendor Inkra Networks. Roberts predicts that “IPSec will have point-to-point dominance for the near future.” SSL is at the wrong layer in the OSI model to provide the type of connectivity remote sites require.
IPSec and SSL differ greatly when it comes to controlling access to back-end servers and other resources. IPSec allows authenticated and authorized users to have network-level access to any available server in their subnet. In other words, when connecting via IPSec, a wide-open TCP/IP connection is established, just as with a local network. Access control falls on the individual servers and not on the point of entry into the network.
Scott Vowels of Comerica’s Corporate Information Security Services department says that giving IPSec VPN access to users is a danger in itself. Opening the whole network and providing so much privilege to users who don’t need it is a mistake, he says. Such total access is great for connecting remote networks or for mobile “power users,” but not advisable for a home user’s PC.
SSL convert Michael Fahey, director of information services at health care organization Adaptis, jokingly describes IPSec’s gatekeeping as: “You gave me a user name and password? Welcome aboard!”