SSL VPN 101

VPN technology began as a complex replacement for dedicated private data circuits between distant networks. The idea was to eliminate expensive monthly telecom fees by sending private data through virtual tunnels across the Internet. The tunnels are encrypted for security, making them nearly as secure as private links at practically zero recurring cost. These savings offset the considerable one-time effort necessary to set up a VPN, which requires dedicated hardware, tedious configuration, and arranging transit for VPN-specific IP protocols across the enterprise firewall.

Today, VPNs are the de facto standard for interconnecting private networks. They work very well for network-to-network interconnections. Alas, the complexity of traditional VPN technology has only increased, as VPN products try to serve other applications, including dial-up users, broadband, and wireless. The number of configurable options has exploded, making VPN configuration an ordeal even for experienced network engineers. Individual remote users must install special client software that can interfere with normal network operation and is itself complicated to configure and operate. Worse, some ISPs block VPN protocols, such as Cisco Generic Routing Encapsulation (GRE) and Layer 2 Tunneling Protocol (L2TP), charging an additional “business class” fee to use them.

VPN vendors eventually devised an ingenious workaround: the SSL-based VPN. At its most basic level, an SSL VPN connection requires that the user have nothing more than a web browser to get connected. The VPN operates over the standard SSL port 443, which is readily passed by firewalls and ISPs alike, without specific configuration or additional fees. Yet sophisticated SSL VPN products can provide nearly all the functionality of an IPSec VPN and even more fine-grained policy control. And all SSL VPN products have one hallmark advantage — ease of setup and support — that your Help desk staff will thank you for.

To understand how you can use SSL VPNs in place of their IPSec brethren, you need to know the spectrum of products and the various feature sets that they support. (Check out the "Major SSL VPN Players" sidebar on page 4 for a listing of products in this area.) Some SSL VPN products are truly clientless, whereas others use lightweight Java or ActiveX applets downloaded automatically from the Web. Some employ simple user ID/password authentication; others can use highly secure digital certificates and/or two-factor authentication. Some give users complete access to the network when connected; others let you restrict access to just the resources that you enable through policy controls. Here’s what the market looks like.

How They Work

To appreciate how SSL VPNs work, first review the underpinnings of IPsec for individual remote users, which makes a host computer appear to be directly connected to your private network behind your enterprise firewall. IPsec does this by creating a virtual network interface directly inside the end-user’s computer that tunnels to the IPsec gateway — either a standalone device or one embedded in the enterprise firewall. This virtual interface looks and behaves like any other LAN or WAN network adapter; in fact, most IPSec VPNs look just like Ethernet cards, complete with their own IP address and route table entries. Once the IPSec tunnel is established, remote users can freely access all network resources at the host end using their private IP addresses, just as if they were “back at the ranch.”

Unlike traditional VPNs, SSL VPNs don’t necessarily create a virtual network interface. The remote user initiates an SSL VPN connection by pointing the web browser at an SSL VPN gateway device, which could be a dedicated appliance or a server running SSL VPN software, such as Microsoft’s Forefront Unified Access Gateway (UAG) 2010. The connection is encrypted with the SSL/TLS protocol, and it can thus exploit the variety of authentication mechanisms that SSL supports. The SSL VPN can also authenticate users via the existing directory infrastructure, whether it’s Active Directory (AD) or the open Lightweight Directory Access Protocol (LDAP) standard. This capability eliminates one more password for users to memorize and means one less ingress point to track for add/drop maintenance.

After a user establishes the SSL VPN browser session, the SSL VPN gateway acts as a proxy for HTTP and HTTP Secure (HTTPS) traffic into your enterprise network. If you’re used to traditional web server SSL, the power of SSL VPN Web access will surprise you. Instead of simply connecting users to a single SSL-enabled Web server, an SSL VPN gateway can route users to any of your web-enabled intranet applications, even if those applications themselves aren’t SSL-enabled. For many users, this is all the remote access they need.

If that were all that an SSL VPN delivered, it would be enough. But there’s more. Unlike basic IPsec VPNs, which attach remote users directly to your enterprise LAN with few to no restrictions, an SSL VPN gateway lets you control precisely which internal servers each user can access. Some gateways even let you control access down to the URL level, limiting which parts of an application remote users can access. This level of control is completely unavailable with IPsec VPNs at any price.

If users need full network-level remote access, using a virtual network interface like the one created by a traditional VPN and enterprise-local IP addresses, you can achieve that via a product-specific “virtual IPsec” connector applet. These applets hook into the user’s OS in the same way that IPsec does, by creating a virtual network interface. But unlike IPsec, these applets require no complex configuration, because the user has no options to choose from. The SSL VPN gateway administrator makes all the choices when configuring the various gateway access policies. Thus, you could let Sam have FTP access to the finance department server, give Alice the ability to send SMTP mail, and prevent Fred from doing either of these things.

These advanced SSL VPN capabilities are all proprietary, but because users have no software to install, there are no compatibility issues to worry about—other than whether the vendor supports your users’ desktop OSs. Not all products support all OSs, but they do all support Windows and Internet Explorer (IE), which, not surprisingly, is where most of the SSL VPN demand is. Beyond OS support, though, you need to understand the main categories that SSL VPN products fall into: simple, hybrid, multifunction, and multifunction hybrid.

Varieties of SSL VPN

These categories might seem complicated, but when you know the SSL VPN feature landscape, they’re easy to understand.

Simple gateway. A simple gateway provides the bare minimum of SSL VPN features, which is actually quite extensive: HTTP and HTTPS proxy, granular access control at the IP address level, password and certificate authentication, and access accounting and audit controls. The user can use most any browser to access a simple gateway, because no applets or ActiveX controls are used. You deploy a simple gateway behind your enterprise firewall, either on the LAN or DMZ port, passing through port 443 traffic, but nothing else. The simple gateway isn’t intended to operate as a firewall, and in many cases you connect it in “one-armed’ fashion, with a single Ethernet port that services both WAN-originated SSL VPN sessions and LAN-destined user traffic.

A major advantage of the simple gateway over a basic IPSec connection is that you aren’t exposing your inside network to a wide range of protocols from end users, so you have a layer of protection against virus transmission and hacker infiltration. There is, however, one new security problem that simple gateways present, as you’ll see in the next section.

Hybrid gateway. A hybrid gateway supports both SSL and IPsec VPNs, giving you a single point of administration for all remote access. It adds no functionality, but often you can find the SSL VPN capability available as an upgrade to an existing IPsec-only gateway. If you currently operate an IPsec gateway, that vendor should be your first consideration on any SSL VPN acquisition plan, as it’s usually better to have one vendor to yell at than two.

Multifunction gateway. A multifunction gateway supports more than just the VPN service. It might also serve as a border firewall, host an enterprise web portal, perform intrusion prevention and detection, and filter virus traffic, to name just a few functions. There are no standards for what constitutes a multifunction gateway, and there’s no real reason for their existence other than purchase and administrative convenience. It might be smarter to keep your SSL VPN capability separate from other network security processes; you’ll preserve product choice down the road and simplify initial SSL VPN rollout and troubleshooting.

Multifunction-hybrid gateway. Multifunction-hybrid gateways combine the features of hybrid and multifunction gateways, delivering a miasma of capabilities that large enterprises might find useful but that are likely to overwhelm the average network tech. So, take care when considering these do-everything boxes!

Vulnerabilities We Have Known

It’s easy to assume that any VPN connection immediately solves all security problems for remote users. But as IPsec users can attest, that’s not necessarily so. An improperly deployed VPN can be just as dangerous as connecting your enterprise LAN to the Internet without a firewall. If a remote network or end user is compromised—whether from virus infection, spyware infestation, or hacker penetration—a VPN (both traditional and SSL) can provide a conduit for these nefarious agents to contaminate your enterprise LAN.

SSL VPNs have a lower risk in this regard because they automatically enforce endpoint-specific access policies, and most also enforce application-specific access policies. And unless you enable a true virtual network interface, SSL VPN connections are application-specific, greatly reducing an interloper’s potential attack surface. The ability to strap down user interactions at the URL level puts even more fine-grained policy control at your fingertips. But as with traditional VPNs, if you don’t configure fine-grained policies, they do you no good.

However, SSL VPNs suffer from several vulnerabilities to which traditional VPNs are immune. The ease with which users can establish an SSL VPN connection— sing only a web browser—can tempt them to connect from unsafe locations, such as unsecured notebook and desktop computers and even public Internet kiosks. This is dangerous because the users have no way of knowing whether the computer they’re using is infected with malware, which could be capturing keystrokes or screen shots. Despite SSL VPN’s inherently tighter policy control, any interloper on a compromised user workstation can see everything the end user sees and do anything the end user does.

Most SSL VPN gateways automatically disconnect remote users from the public Internet while a VPN tunnel is active, forcing users to browse the Internet through their VPN tunnel. This avoids the so-called split-network attack, in which a hacker gains real-time access to an enterprise LAN through a VPN tunnel. In an SSL VPN, split-network protection simply proxies all browser access through the VPN while blocking all other Internet protocols. But the split-network vulnerability is just one of several.

A second vulnerability is even more insidious than the split network, and there is currently no known fix, only a circumvention. This vulnerability could lead to an intruder taking over a user’s machine entirely; it’s due to a flawed implementation of the applet that many SSL VPN products install at the start of an SSL VPN session. If the Java or Active X applet has a feature that enables launching a local program on the user’s computer, such as a client application, that feature could be exploited by a hacker to launch malicious code as well, which could be as simple (but still devastating) as a keystroke logger. Generally, this feature is a convenience to the end users: automatically launching the local program, such as an order-entry application, to simplify operation for the user. To circumvent this problem, you must disable the application-launch feature.

A third class of vulnerability is virus and spyware infestation, which can lead to injecting malware behind your enterprise firewall. Malware can get a foothold by piggybacking email attachments and file transfers, or—if SSL VPN protocol connectors are employed—over an arbitrary TCP/IP protocol. These exploits are sometimes called passive, because they’re autonomous programs that have no specific target in mind and simply strive to spread themselves to all available targets in a network. SSL reduces the number of these vulnerabilities but doesn’t eliminate them.

There’s really only one defense against these latter two classes of vulnerability: tight control over the computers used to access your VPN. This means strictly enforcing virus and spyware scanning, prohibiting the use of remote systems on unprotected networks, and educating users to ensure that they understand the risks of attempting to bypass security policies. Some SSL VPN gateways assist with malware protection through applets that verify that virus protection is intact on a user’s system before admission to the network, and by performing intrusion detection and prevention on remote traffic.

As an adjunct to SSL’s normal single-sided authentication, you should enforce two-way validation of both the remote user and the destination VPN. The easiest way to do that is with digital certificates distributed from your public key infrastructure (PKI). Fortunately, all but the least sophisticated SSL VPN gateways support such authentication. Another security bulwark worth investing in is two-factor authentication, which in addition to the normal user ID and password logon requires a second-level password, either through a dedicated security fob or USB key, or via an out-of-band communication. A very clever form of the latter approach is a gateway that sends to a remote user’s cell phone an SMS message containing a one-time password that the user must also enter to gain access.

SSL VPN Packaging

The vast majority of SSL VPN gateway products are hardware-based appliances, but there are also software products that run on UNIX or Windows servers. Both hardware and software products generally charge by the number of users supported. With hardware, this limitation may be enforced by the capability of the underlying hardware, or may be a strictly controlled user count. Software products, including Microsoft’s Forefront UAG, often require per-user licenses purchased separately.

Many hardware firewall appliances now have optional SSL VPN features you can add for an additional license fee, which typically includes a 30-day trial to let you try out the product first. Be aware, however, that SSL VPN encryption processes can impose a significant CPU load on an enterprise firewall, unless the device includes dedicated hardware encryption processing. Even then, SSL VPN traffic can interfere with other non-encrypted traffic, such as VoIP, so it might be best to keep SSL VPN capabilities separated in one device or server. As with the proverbial TV-with-built-in-VCR, you might find that the bundled SSL VPN complicates future upgrades to either the firewall or SSL VPN aspect of the gateway device.

Finally, when looking at software-only SSL VPNs, keep in mind that without dedicated encryption hardware, these products will support a limited number of users. Although per-user licensing costs often become attractive with bulk purchases of 200 or more seats, or if you have enterprise licensing already entitling you to SSL VPN capabilities, few off-the-shelf servers can support even a fraction of that number of simultaneous VPN tunnels.

Try Before You Buy

Armed with an understanding of the differences between traditional and SSL VPNs, and knowledge of the ease-of-use advantages of the latter, you’re ready to go shopping for an SSL VPN gateway. Be sure to consider your users’ requirements and select a product with adequate controls for the vulnerabilities that your user community faces. Most VPN products, including hardware appliances, have low-end editions that cost just a few hundred dollars, making them cheap to try before you spend money on the full-sized enterprise version. Best of all, SSL VPN products have no network-infrastructure compatibility concerns, so you can start testing today!

Major SSL VPN Players

AEP Networks' AEP Netilla, Series A (hardware)—www.aepsystems.com

Array Networks' SPX series (hardware)—www.arraynetworks.net

Astaro's Astaro Security Gateway virtual appliance (hardware/software)—www.astaro.com

Avaya's VPN Gateway 3000 series virtual appliance (hardware/software)—www.avaya.com

Barracuda Networks' Barracuda SSL VPN virtual appliance (hardware/software)—www.barracudanetworks.com

Billion's BiGuard SSL series (hardware)—www.billion.com

Check Point's (Nokia) Connectra (hardware/software)—www.checkpoint.com

Cisco Systems' AnyConnect for VPN2000, ASA-5500 (hardware)—www.cisco.com

Citrix's Citrix Access Gateway (hardware)—www.citrix.com

Cyberoam's Cyberoam SSL VPN virtual appliance (hardware/software)—www.cyberoam.com

F5 Networks' FirePass, Big-IP Edge Gateway (hardware)—www.f5.com

Fortinet's FortiGate Series (hardware)—www.fortinet.com

Juniper Networks' Secure Access (SA) series (hardware)—www.juniper.net

Kerio Technologies' Kerio Control (software)—www.kerio.com

Linksys' (Cisco) RVL200 SSL/IPSec VPN (hardware)—www.cisco.com

Microsoft's Forefront Unified Access Gateway (software)—www.microsoft.com

Netgear's ProSafe SRX5308 (hardware)—www.netgear.com

OpenVPN's OpenVPN ALS (software)—www.opernvpn.net

PortWise's PortWise Access Manager (software)—www.portwise.com

SonicWALL's SonicWall SSL-VPN, E-Class (hardware)—www.sonicwall.com

Stonesoft's SSL-1030, -1060, -6000 virtual appliance (hardware/software)—www.stonesoft.com

Vyatta's Vyatta Remote Access (hardware/software)—www.vyatta.com

WatchGuard's SSL 100, SSL 560, ProSecure UTM (hardware)—www.watchguard.com