For years, software solutions based on IPSec have ruled VPNs. But new Secure Sockets Layer (SSL) appliances are changing all that.
Tried-and-true IPSec provides a layer 3 VPN solution that terminates at the firewall and grants remote users access to the entire network. On each remote computer, a client must be installed and configured — either third-party software (typically licensed from a network hardware vendor) or a client built into the operating system, such as L2TP (Layer 2 Tunneling Protocol) and PPTP (Point-to-Point Tunneling Protocol) in Windows 2000 and XP.
SSL solutions, on the other hand, operate at the application level and terminate at an appliance inside the firewall. Network administrators use the box to control user access application by application in conjunction with network authentication and authorization services. And because SSL is browser-based, users can log on securely with a Web browser using almost any device.
A host of vendors now offer SSL appliances, including Array Networks, Aventail, F5 Networks, Neoteris, and Netilla. According to research firm In-Stat/MDR, a mere US$21 million in SSL devices was shipped in 2002. That number is expected to rise to $1.3 billion by 2007.
Away from the office, users may need to tap data stored behind the firewall using various devices; not just the corporate laptop, but also handhelds, computers at customer sites, or a PC in the bedroom.
SSL VPNs are picking up steam mainly because, unlike established IPSec VPNs, client software needn’t be installed on the user’s computer. Jeffrey A. McConocha, president of NCS DataCom, a VPN solution provider using Neoteris Inc. SSL appliances, says switching his customers to an SSL-based VPN “has virtually eliminated client (tech) support for mobile users.”
Another plus is that remote users don’t need to worry about local firewalls when they log on via SSL VPNs. By contrast, attempts to connect via IPSec client behind a NAT firewall usually fail. “SSL provides a nice, clean solution for NAT transversal,” says Steve Schall, director of security application product management at Nokia.
GRANULAR SECURITY POLICIES
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.
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 Corp. 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.
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 Inc. 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.
Connecting to files and applications using SSL can be as easy as browsing to a portal page and clicking on a link. Through access control lists and user policies, applications, data and servers are exposed to the Internet through the SSL VPN appliance.
Access control policies are extremely granular, allowing for pinpoint accuracy when granting access to protected resources, something IPSec VPNs lack. SSL moves the access control away from the servers and out to the edge where the tunnel terminates. Because it is not a network-level connection, none of the servers behind the appliance is immediately exposed to the user. So, all authorization, authentication, and policy enforcement occurs on a device just behind the firewall, but off the individual servers.
This is an important concept with SSL VPNs. Unlike an IPSec tunnel, when users connect to the VPN appliance, even though they have a secure session, they still don’t have access to resources on the LAN. Based on group membership, users can only connect to systems specifically defined in the access policy.
BROWSER-BASED CONCERNS
Vowels, who has deployed both IPSec and SSL VPNs, clearly has faith in both VPN schemes, but SSL’s browser-based access raises concerns. “We want folks using SSL to exercise discretion,” Vowels says. He worries about where his users will be accessing applications; untrusted sites such as Internet cafes and other locations pose a risk to a company simply because the provider can be anyone. Cameras that record computing or undetectable devices that capture keystrokes are not unheard of.
Some SSL VPN appliances include “cache cleaning” technology that purges the browser’s cache and temp files on exit. This also helps prevent private information from being intercepted.
So far, most adopters are not too concerned about the cipher strength of SSL VPNs.
Can something that sounds as good as SSL really be that good? Well, almost. SSL is a very capable platform, but it’s not all things to all people. Policy generation requires more effort and can be more prone to errors with SSL than with IPSec tunnels. In part, this is because SSL appliance vendors have not “wizardized” the process.
The number of choices and options available during policy creation can be overwhelming. For example, the Neoteris Access Series VPN appliance provides a high level of policy granularity, but for each level of access control, a choice must be made. SSL’s policy creation plays against IPSec’s client support time and administrative costs, but overall, policy definition for SSL takes up less time and creates fewer problems than IPSec client support.
So, IPSec or SSL? In fact, most midsize-to-large organizations need both. Which technology gets deployed where depends on who needs access. Remote IT administrators that require full, network-level access need IPSec; so, generally, do remote offices. But minimal client deployment and application-level authorization argue that just about everyone else should connect via SSL.