When a virtual private network (VPN) does its job correctly, remote users don’t notice it’s there. Packets move from site to site, user to user.
Encryption algorithms scramble the data and then safely unscramble it at the other end. Information flows. Work gets done.
But this unseen extension to the enterprise network is in the midst of a major technology shift — the biggest since the mid-’90s, when VPNs first provided inexpensive Internet alternatives to carriers’ proprietary private networks. 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 Layer 2 Tunneling Protocol (L2TP) and Point-to-Point Tunneling Protocol (PPTP) 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 authorisation 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 US-based research firm In-Stat/MDR, a mere $US21 million in SSL devices was shipped in 2002. That number is expected to rise to $US1.3 billion by 2007.
More options for mobility
Away from the office, users may need to tap data stored behind the firewall using various devices; not just the corporate laptop but handhelds, computers at customer sites, or a PC in the bedroom. The need for multiple entry points was a key reason Tom Paceck, Virtua Memorial Hospital’s assistant vice-president of technology, chose an SSL.
“For us, it all comes down to mobility,” he said. “We never know where our people will be to access applications.” Many of the physicians on the hospital staff are mobile, and many more lack the patience to carry around a laptop or sign on through a VPN client.
SSL VPNs are picking up steam mainly because, unlike established IPSec VPNs, client software needn’t be installed on the user’s computer. Jeffrey McConocha, president of NCS DataCom, a VPN solution provider using Neoteris SSL appliances, said switching his customers to an SSL-based VPN had “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 network address translation (NAT) firewall usually fail.
“SSL provides a nice, clean solution for NAT transversal,” director of security application product management at Nokia, Steve Schall, said.
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.
Tunnelling through the bowser
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 said, 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, co-founder of security appliance vendor Inkra Networks, Dave Roberts, said.
He predicted: “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 authorised 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.
Comerica’s Scott Vowels said that giving IPSec VPN access to users was a danger in itself.
Opening the whole network and providing so much privilege to users who don’t need it was a mistake, he said. Such total access is great for connecting remote networks or for mobile power users, but not advisable for a home user’s PC.
Director of information services at health care organisation Adaptis and SSL convert, Michael Fahey, jokingly described IPSec’s gatekeeping as: “You gave me a user name and password? Welcome aboard!”
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 are immediately exposed to the user. So, all authorisation, 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.
Managing SSL risks
Vowels, who has deployed both IPSec and SSL VPNs, clearly has faith in both VPN schemes, but SSLs browser-based access raises concerns.
“We want folks using SSL to exercise discretion,” he said.
Vowels is worried though 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.
Paceck had total confidence in the technology.
Currently, Virtua Hospital’s security policy requires only one type of authentication — but that could change if the US Health Insurance Portability and Accountability Act (HIPAA) requirements change to necessitate the use of two forms of identification.
Packe said this would be easily accomplished by issuing smart card or biometric devices that physicians can carry on their person.
Changing of the VPN guard?
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 “wizardised” 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 organisations 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 the advantages of minimal client deployment and application-level authorisation argue that just about everyone else should connect via SSL.