In the beginning, there was dialup remote access. Users who needed to access resources on the company LAN from home, while on the road, at a customer's location or when otherwise off-site could use a modem to dial into a server on the LAN. Due to the limitations of modem technology, this was slow, but fairly secure since a direct circuit phone line connection was being used. It could be expensive if long distance charges were involved.
Then along came the Internet. As almost all company networks became Internet-connected, and Internet connectivity became almost ubiquitous— available at low cost to home users, in hotels and airports, etc.—virtual private networking (VPN) became the solution of choice for remote access. There were many advantages: broadband connections made it fast, you could connect from anywhere in the world without incurring long distance charges, and encryption technologies made the communications secure even though they were being sent over a public network.
But all VPNs are not created equal. Thus came the VPN wars, as different VPN methods and protocols struggled for dominance. Microsoft's Point to Point Tunneling Protocol (PPTP) was soon overshadowed by its more secure successor, the Layer 2 Tunneling Protocol (L2TP), which combined features of PPTP and Cisco's Layer 2 Forward (L2F) and offered certificate-based authentication. Outside the Microsoft realm, VPNs were commonly based on Internet Protocol Security (IPSec). Whereas PPTP and L2TP operate at the data link Layer (Layer 2) of the OSI model, IPSec operates at the network Layer (Layer 3). IPSec is a set of protocols that can provide more than just encryption of the traffic in the tunnel (data confidentiality); it can also provide authentication of the sender and integrity of the data (assurance that it hasn't been changed in transit). However, it's complex and different vendors implement it slightly differently.
Enter the latest kid on the VPN block: SSL. The Secure Sockets Layer protocol works at the Application Layer (Layer 1). It has been used for quite some time to secure Web transactions such as e-commerce and Internet banking. Now it's an emerging trend in virtual private networking. In this first article in a four-part series, we look at the different categories of SSL VPNs, advantages and disadvantages of using SSL for your VPN, and the basics of how an SSL VPN works.
What is an SSL VPN?
First, let's straighten out a fundamental nomenclature error. For all this talk of SSL VPNs, in many cases the type of remote access connection provided by SSL and called an SSL VPN is not, technically, a VPN connection. That's because VPN stands for virtual private network—when connected through a true VPN, the client becomes a virtual node on the local network, with full network-Layer access. A real VPN connection is protocol agnostic.
SSL, on the other hand, is protocol-dependent. When deployed in its clientless form, it connects you to specific applications on the local network, but does not give you full network access. While any firewall can be configured to support any application through a VPN by configuring the correct ports, an SSL gateway must be built to support specific applications. However, because the term has come into common usage for many different types of SSL connections (just as the term "cable modem" is commonly used for a device that is not a modulator-demodulator), we'll continue to use it throughout this series.
Another inaccuracy that has grown up around the topic of SSL VPNs is that they are always clientless. Even if the SSL connection uses only a Web browser, the browser is still a piece of client software (albeit one that most computers already have installed). Many SSL VPN solutions require that you install browser plug-ins, Java or ActiveX controls. Some vendors require that you use a particular Web browser (vendor/version) for full access. For example, CheckPoint's Connectra SSL gateway requires that you use IE version 5.5 or above for advanced access (ability to access network file shares in addition to e-mail and Web applications).
Finally, even the term SSL itself is inaccurate (or rather, outdated). The current version of the protocol (v3) has been renamed by the Internet Engineering Task Force to Transport Layer Security or TLS. For the sake of conformity, we'll continue to refer to it by its old name here.
Now that we've got the name game out of the way, let's take a look at the different types of SSL VPNs. We've broken SSL VPN solutions into four basic categories:
- The clientless SSL VPN
- The semi-clientless SSL VPN
- The client-based SSL VPN
- The full network access SSL VPN or true VPN
The clientless SSL VPN
Again, we put the term in quotation marks because you must have client software—a Web browser—to use this VPN solution. However, you can use any Web browser that supports SSL (almost all modern browsers) and you don't need to install anything extra (Java, ActiveX controls, plug-ins). You generally will be able to access Web based applications only, so this is not a true VPN. However, it can be a good solution when remote users only need access to specific Web-based application.
The semi-clientless SSL VPN
These solutions also use a Web browser as the client, but you have to install an add-on, usually Java or ActiveX. Users can access non-Web based applications, such as Outlook. The add-on encapsulates the native protocol used by the application and sends it in an SSL encrypted tunnel. It's presented to the client as if it were a Web-based application.
The client-based SSL VPN
These solutions require client software to be installed, which acts as a Winsock proxy. Users have network level access to applications on the LAN, but not all protocols are supported.
The full network access SSL VPN
These solutions work like IPSec VPNs except that they use SSL instead of IPSec for encryption and tunneling. They use UDP instead of TCP due to synchronization issues that would present problems running TCP over TCP. Unlike other SSL VPNs that are used for remote access VPN only, these solutions can be used for either remote access or site to site VPNs.
Why (or why not) use SSL for your VPN?
SSL has some advantages over more traditional VPN methods, both for users and for administrators. It also has some drawbacks.
Advantages of SSL VPN
A major benefit of SSL VPNs to the user is simplicity. Rather than having to configure a VPN connection, the user can simply click a link on the desktop to go to a portal Web page, which is automatically customized for the user based on which resources the administrator has given that user access to.
Because they can be established from any SSL-enabled Web browser, most SSL VPN connections are also operating system independent. You can establish the connection from Windows, Linux, Macintosh, or even a PDA or phone that has an SSL-capable browser.
From the administrative side, there are a bevy of advantages:
- Less understanding of protocols is necessary than with conventional VPNs. The SSL approach is to give access to particular applications or servers, rather than having to bother with ports and protocols. Thus SSL VPNs are easier to deploy and maintain than are IPSec VPNs.
- Another advantage of SSL is that it doesn't suffer from some of the compatibility problems that arise with IPSec, such as when trying to interoperate with Network Address Translation (NAT) implementations that don't support NAT Traversal (NAT-T).
- Because almost all firewalls are configured to allow outbound traffic on ports 80 (HTTP) and 443 (HTTPS), SSL (which uses port 443) will work through firewalls without any special configuration.
- Unlike IPSec, which is deployed slightly differently by different vendors, SSL is highly standardized.
- SSL VPNs can also provide a security advantage. When access is restricted to specific applications, the chances of unauthorized access are reduced.
From management's point of view, SSL VPNs are often much less costly to deploy than IPSec VPNs. This is because, with clientless SSL VPNs, there is no cost for proprietary client software licenses, no administrative overhead involved in installing client software, and less time required for client technical support due to the ease of use.
The downside of SSL VPN
SSL VPNs, even those that claim to provide full network access, may not work as well with complex applications as traditional VPNs. In addition, the ability to connect via SSL from almost any browser can present security hazards—for example, a user can unwittingly introduce a virus or worm by connecting from an infected machine.
It's a good idea to deploy extra security measures. For example, an applet can be downloaded to each client that attempts to connect, which will scan for files that indicate virus infection or for open ports, or determine whether the client is running a personal firewall. SSL gateways can also perform application Layer filtering to ensure that malicious packets don't get into the company LAN.
Another concern is that when a user accesses company data from a public computer, such as those in libraries or Internet cafes, he may download private data to the public computer and leave it there for subsequent users to find. This can be prevented by an applet that isolates any files that the user downloads over the VPN connection and automatically deletes them at the end of the session. The credentials used to log onto the company network can also be automatically deleted.
User authentication is limited to usernames and passwords, unless you install add-on software for stronger authentication. This will increase cost, but will also increase security. You can even get SSL VPN solutions that support multi-factor authentication with tokens, smart cards or biometric identification.
Perhaps the biggest downside to SSL VPNs is that applications must support SSL in order to work, or you must use a protocol redirector that can be tricky to use.
How an SSL VPN works
The SSL protocol operates at the bottom of the Application Layer. There are several different techniques that a vendor can use to provide SSL functionality:
- The simplest method is the application layer proxy. The problem is that this type of SSL VPN is limited to Web-based applications and e-mail. The application Layer proxy works from any SSL-enabled Web browser and doesn't require any additional software.
- The second method is protocol redirection. This technique gives you more functionality, as non-SSL applications can be accessed because they're encapsulated in the SSL tunnel. However, client software is required so users may not be able to establish this type of connection from public computers that don't allow the installation of software.
- The third type of SSL VPN uses remote control enhancement. That means they're dependent on a protocol such as the Remote Desktop Protocol (RDP) used by Windows Terminal Services/Remote Desktop Connection. They combine SSL VPN with the remote control protocol so that users can access documents and applications without actually downloading them to the remote machine. That helps a lot if the user needs to connect from a slow machine or thin client, or over a slow Internet connection. It also is more secure because if the user is using a public computer, the documents he accesses are never downloaded to that machine's hard disk and thus there is no danger of them being left there for someone else to see.
The details of how an SSL VPN works depends on the method used by the particular vendor. For example, with an application proxy, here's the process:
- You deploy an SSL/proxy server on the internal LAN (behind the firewall). This proxy server is made available to the Internet.
- To connect to the LAN, the user enters the proxy server's URL in his Web browser.
- The proxy server authenticates the user.
- The proxy server passes communications between the remote user and the application server(s) on the internal network.
For more information about particular SSL VPN solutions offered by different vendors, see their Web sites:
Debra Littlejohn Shinder, MCSE, MVP is a technology consultant, trainer, and writer who has authored a number of books on computer operating systems, networking, and security. Deb is a tech editor, developmental editor, and contributor to over 20 additional books on subjects such as the Windows 2000 and Windows 2003 MCSE exams, CompTIA Security+ exam, and TruSecure's ICSA certification.