Remote Access

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

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.

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

Series Summary
Securing remote access with SSL VPNs

Part 1: Reinventing remote access
Part 2: Deploying an SSL VPN appliance
Part 3: Defining SSL VPN access policies
Part 4: Adding SSL VPN endpoint controls
Part 5: Using SSL VPN access methods

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
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 offsite 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 reuse 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.

Go to page two: Uncharted territory >