Remote Access

Securing Remote Access with SSL VPNs
Part 1: Reinventing Remote Access
—continued

by Lisa Phifer VP Core Competence, Inc. [July 7, 2008]

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 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

1. 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 rewrites server responses and tunnels them back to the user over SSL/TLS.
   
   
2. 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.
   
   
3. 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.
   
   
4. 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 us that SSL VPN had become their preferred remote access offering, but all continued to support IPsec as well, giving customers a choice.

Clearly, service providers need to be familiar with SSL VPNs as a flexible alternative for securing remote access. To illustrate what SSL VPNs can do, Part 2 of this series will take you on a guided tour of one popular SSL VPN appliance. Parts 3 and 4 will examine how SSL VPN policies enable granular control over remote users, devices, and the resources they are permitted to reach. Finally, Part 5 will demonstrate SSL VPN access methods, from basic web portals to full-blown network connection.

—End

< Back to page one