How to: Get Secure Remote Access with SSL VPNs (Part 1)

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Today’s users require secure remote access from an increasingly diverse collection of devices, many of which are unknown, unmanaged, and potentially dangerous. In this series, we illustrate how providers can use SSL VPN appliances to deliver flexible-but-safe “anywhere” access to network resources.

In the late 1990s, IPsec emerged as a standard for enabling Internet-based remote access to private networks. Since then, Secure Sockets Layer (SSL) VPN appliances have steadily eroded IPsec market share. According to Gartner, SSL VPN revenue reached $340 million worldwide in 2007, and will continue growing an average of 21 percent annually through 2011. Forrester Research estimates that 40 percent of enterprises are now upgrading to SSL VPNs or have already deployed one.

Why are so many companies investing in SSL VPN technology? In this series, we examine where SSL VPNs came from, what these sophisticated appliances can do, and how service providers can tap this technology to deliver more granular and flexible secure remote access to employees, suppliers, and customers.

Getting connected
Overcoming barriers
Uncharted territory
Beyond Web
Adapting to customer needs
RELATED NEWS AND ANALYSIS

Getting connected

A decade ago, companies were just starting to grapple with the cost of remote access. Eliminating pricey dial modem pools by shifting road warrior communication onto the public Internet made economic sense. To prevent eavesdropping on Internet traffic, travelers started tunneling into corporate networks through remote access VPN concentrators that implemented IP security (IPsec).

Standard IPsec was designed to protect IP packets by encrypting their data payload, verifying their integrity, and discarding replayed packets. To negotiate security services and crypto keys, IPsec relies on the Internet Key Exchange (IKE). IKE establishes IPsec tunnels as needed between mutually-authenticated peers.

IPsec and IKE excel at securing all IP packets exchanged between peer gateways in a site-to-site VPN. However, IKE had to be stretched to meet common remote access needs. Extended authentication (XAUTH) was added to relay user logins and passwords. Vendors invented ways to assign private IP addresses to remote hosts. To use these proprietary tweaks, employers had to install vendor-supplied VPN clients.

In fact, road warrior laptops had to be provisioned with not just VPN clients, but also business applications and security programs. IT administrators had to ensure that every remote host was correctly-configured and malware-free, because IPsec tunnels joined those hosts to the corporate network, bringing them inside the security perimeter.

As offsite workforces grew, so did VPN administration costs. When residential broadband replaced dialup, more workers started asking for remote access from home. Internet cafes and public PCs in hotels and business centers generated demand for remote access from those platforms, as well. Mobile workers spent less time at the office and started checking corporate e-mail from handheld devices. More suppliers, customers, and business partners needed off-site access to business applications and data.

Overcoming barriers

These demands increased remote workforce size and diversity, while bringing new IT challenges and security threats. Installing a VPN client on a worker’s home PC isn’t very palatable—what happens when another family member uses that PC or it becomes infected with malware? Installing a VPN client on a public hotel or kiosk PC is clearly out of the question. And mobile handhelds that cannot run Win32 IPsec clients or business applications pose additional problems.

On the other hand, Web browsers are already present on just about all of those devices. Browsers use the Secure Sockets Layer (SSL) protocol or its standard descendant, TLS, to encrypt and verify HTTP messages sent by Web applications. Why not re-use those Web browsers and their native tunneling protocols to deliver many of the same security services as IPsec, without having to install an IPsec VPN client?

SSL VPN appliances emerged to satisfy this growing demand for “clientless access” from personal computers, public PCs, mobile handhelds, and business partner devices. These products use the ubiquitous Web browser as a secure access delivery platform. In many cases, a temporary “dissolvable” agent—an Active X control or a Java applet—can be delivered through the browser to support client-side processing (see figure). This reduces client administration costs while accommodating more diverse users and devices.

Figure 1-1: Using a Web browser and VPN appliance for “clientless access”

Uncharted territory

Of course, giving unmanaged, unknown, and potentially compromised devices full access to your entire network would be extremely dangerous. Home and business center PCs may have raised these concerns, but similar worries apply to IT-managed laptops that run security programs which are out-of-date or mis-configured.

Fortunately, SSL VPNs can mitigate those risks in two ways. First, instead of connecting trusted hosts to entire networks, SSL VPNs can connect authorized users to selected applications and data objects. Offering finer-grained “need to know” access can reduce risk by limiting business asset exposure.

Second, SSL VPN access decisions can reflect both user identity and device (tunnel endpoint) security. Adjusting resource authorizations in this way can minimize threat exposure on different devices. This is even more important when the same user attempts access from more than one location—what Jane should be able to do when working from home may be quite different than when she logs in from a business center.

For example, an SSL VPN might provide read/write file access on managed laptops, read-only access on unknown endpoints, and no access on infected devices. Furthermore, as each user navigates the SSL VPN-protected file system, the only folders visible are those accessible to this individual. This kind of user-focused, endpoint-aware policy is necessary to safely expand remote access to diverse communities.

Beyond Web

Like IPsec VPN concentrators, SSL VPN appliances are deployed at trust boundaries, where they authorize, secure, and audit access to private resources. Instead of IPsec, those appliances use SSL or TLS to tunnel traffic securely across the Internet. But precisely how they apply SSL/TLS, and what those tunnels carry, varies quite a bit.

Some early SSL VPN products focused on Web-based applications, staying completely within the browser paradigm. When Web apps proved far too limited for most remote user needs, SSL VPN products evolved. Most incorporated Web front-ends for popular applications and added more generic access methods. Today, most SSL VPN appliances support two or more of the access methods illustrated below (see figure).

Fig 1-2: There are many possible access methods for VPN appliances

The first method provides access to any Web-based application. The browser tunnels HTTP over SSL/TLS to the VPN appliance, much as it would to any Web server. The VPN appliance operates as a Web proxy, mapping external URLs to internal addresses before forwarding HTTP to that private Web server. On the return trip, the appliance re-writes server responses and tunnels them back to the user over SSL/TLS.
The second method uses the browser to interact with non-Web applications—for example, communicating with popular mail, file, and terminal services. Here, the VPN’s dissolvable agent becomes the application client, sending HTTP requests over SSL/TLS to the VPN appliance. The appliance maps HTTP into native application protocols, relayed to a private mail/file/terminal server. This method requires application-specific content translators; most appliances now provide built-in translators for a few common business applications.
The third method uses an SSL VPN agent to accommodate non-browser-based client applications. The user interacts with TCP client applications, installed locally in the usual manner. The SSL VPN agent binds to those TCP ports and forwards native application protocols through the SSL/TLS tunnel. The appliance acts as a reverse proxy, relaying application messages to and from private TCP servers. This is more general purpose and can support a wider variety of TCP client/server applications. However, activating the agent may require a specific browser, plug-in, or even administrative privileges on the remote host.
The fourth method is less widely-implemented but even broader. Here, the SSL VPN agent tunnels not TCP sessions, but IP packets. This is logically similar to IPsec and can be used to deliver full network access to applications that require and deserve it—like VoIP on a managed laptop. In this case, SSL VPN products may actually install a persistent “network connector” agent. But they can use the appliance portal and policy engine to deliver agents and provide each user with a choice of access methods.

Multiple access methods may appear confusing at first, but they have evolved to meet different user, device, and application needs. Any organization that must support a large diverse workforce will have trouble shoe-horning everyone into a single remote access solution. This is why many have moved some IPsec VPN users onto SSL VPNs and/or deployed SSL VPNs to satisfy previously-unmet remote access needs.

Adapting to customer needs

Early SSL VPN appliances were marketed to large enterprises—those organizations experiencing the most IT pain as they tried to expand legacy VPNs. Soon thereafter, service providers that offered enterprise remote access products—either through resale or as managed services—started adding SSL VPNs to their portfolios. Over the years, scaled-down SSL VPN products emerged for mid-sized and small businesses too.

ISP-Planet’s bi-annual Managed Security Service Provider survey (most recent survey: 2006) illustrates this market shift. In 2003, just 7 out of 30 surveyed providers offered SSL VPNs. By late 2006, that number had grown to 80 percent. Many providers told ISP-Planet that SSL VPN had become their preferred remote access offering, but all continued to support IPsec as well, giving customers a choice.

Part 2 of this series will take you on a guided tour of one popular SSL VPN appliance.

For more on VPNs, read “Retailers Need to Shore Up Defenses,” “Wi-Fi Planet Guide to Hotspot Safety,” and “Travelers Beware: Survey Exposes Airport Wi-Fi Vulnerabilities.”

Lisa Phifer owns Core Competence, a consulting firm focused on business use of emerging network and security technologies. She has been involved in the design, implementation, assessment, and testing of NetSec products and services for over 25 years.

This article was first published on ISPPlanet.com.