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

  • 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

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

  1. You
    deploy an SSL/proxy server on the internal LAN (behind the firewall). This
    proxy server is made available to the Internet.
  2. To
    connect to the LAN, the user enters the proxy server’s URL in his Web browser.
  3. The
    proxy server authenticates the user.
  4. 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: