Guide to SSL VPN
Hello, SSL VPN. Goodbye, IPSec VPN
SSL VPN market is a success story
By Tim Greene
So complete is their success that IPSec VPNs have fallen off the radar screen of companies seeking the advice of Gartner consultants. "Gartner clients no longer ask about new IPSec remote-access installations or expanding legacy IPSec remote access," according to a report by the firm.
Businesses that maintain IPSec VPNs for remote access do so because the gear is already installed and hasn't reached the end of its life. Or they keep it around for specific limited use, generally by IT professionals that need to get into the network to fix things and want full network access.
Some Gartner clients have ceased new IPSec remote-access deployments, and others have ripped out IPSec and replaced it with SSL, citing the benefits of easier administrative provisioning of user accounts and a simpler user experience with VPN sessions, according to the report.
Businesses are interested in SSL VPNs because browsers can reach them. That makes them more flexible than IPSec, which requires separate client software on remote machines, Gartner says.
This dovetails with evolving business needs, such as the increased use of consultants and more extensive alliances that require sharing network resources with partners. Businesses that rely on itinerant workers or people working occasionally from home who may not have access to a company-managed machine also drive the popularity of SSL VPNs.
"SSL VPNs have superseded IPSec as the easiest choice for casual and ad hoc employee VPN access requests and also for business partners, external maintenance providers and retired associates," Gartner says.
The firm predicts that by 2008, SSL VPNs will be the primary remote-access method for most businesses. Sales of SSL VPN gear increased 26% in the first three quarters of 2006, compared with 2005, Gartner says.
SSL VPNs also are attractive because, with the download of SSL VPN agents, they can duplicate the network-layer access afforded by IPSec VPNs if that is what customers want. Without these agents, using just a browser on remote machines, SSL VPNs can establish only application-layer connections.
When Internet-based VPNs came on the scene in the late 1990s, their appeal was obvious: It is less expensive to buy Internet access and make WAN connections over it than to buy dedicated circuits, a frame relay or MPLS service. While its advantages seem obvious now, SSL had a tough fight establishing itself that required innovation.
SSL is a standard that ensures a secure, encrypted communications between applications, and the most popular use is secure links between Web browsers and Web servers. SSL is independent of whatever underlying protocols it runs on, including IP. IPSec on the other hand, is a collection of standards that also support secure, encrypted communications only at the IP layer. IPSec is independent of the applications that run over it, so an IP application can run through an IPSec tunnel.
SSL's restriction to supporting only Web applications was an initial stumbling block. When SSL VPNs requiring just a browser came on the scene, the implication was that businesses no longer needed to distribute and maintain client software on the remote machines, as long as customers wanted only to reach Web applications. That ruled SSL out for many potential customers whose users needed to access traditional client-server applications.
But increased use of Web applications and tacking a Web front-end on non-Web applications boosted SSL's fortunes. SSL VPN vendors adapted by pushing Java or Active X SSL VPN agents to the remote machines on the fly. These plug-ins gave the remote computers the ability to create network-layer connections comparable to IPSec, but without having to distribute dedicated VPN client software.
Also giving SSL VPNs a lift was the rise of Wi-Fi networking in corporate environments. With initial Wi-Fi security problems that allowed drive-by hacking of corporate networks, security experts sought a means to tighten access through wireless access points.
VPNs filled the bill because they could be added to existing wireless deployments to authenticate users to the network and to encrypt traffic as it traveled over the air. SSL VPNs in particular were attractive in this instance because they didn't require a client.
Inherent drawbacks of IPSec also contributed to the success of SSL. IPSec always proved complex. The more sites that connect to each other, the more secure links or tunnels need to be defined and maintained. Then there was the issue of installing and maintaining clients.
Use of unmanaged machines to access SSL VPNs gave rise to technology that scanned endpoints before they were allowed VPN access to determine how much to trust them. This technology presaged network access control (NAC), which sought to assure that machines attaching to networks met security policies.