SSL Overview

SSL is an emerging VPN implementation in the marketplace. It was designed for remote access solutions and does not provide site-to-site connections. SSL VPNs provide secure access primarily to web-based applications. Because SSL uses a web browser, users typically do not have to load any special client software on their desktops.

SSL VPNs operate at the session layer of the OSI Reference Model. And because the client is a web browser, only those applications that support a web browser, by default, will work with a VPN solution. Therefore, applications such as Telnet, FTP, SMTP, POP3, multimedia, IP telephony, remote desktop control, and others don't work with SSL VPNs because they don't use a web browser for their front-end user interface. Of course, many vendors use either Java or ActiveX to enhance SSL VPNs by supporting non-HTTP applications, POP3 and SMTP e-mail clients, and Microsoft Windows file and print sharing. For example, the Cisco SSL VPN implementation supports non-web-based applications such as Citrix, Windows Terminal Services, and many others. Plus, some vendors use Java or ActiveX to deliver other SSL VPN components, such as additional security functions for removing any traces from the PC of a user's activity after the SSL VPN has been terminated, in addition to others. Cisco refers to their SSL VPN implementation as WebVPN.

Note

Be aware that each networking vendor has a list of non-HTTP applications that it supports. Therefore, you should scrutinize a vendor's SSL VPN offering carefully and compare this to your users' needs before choosing between different SSL VPN vendors. In some cases, a vendor might even offer full tunneling of network-level traffic via an SSL VPN, making the solution more similar to the capabilities of a Layer-3 VPN implementation such as IPsec.

 

SSL Client Implementations

A main reason that network administrators like the appeal that SSL VPN implementations offer is that SSL VPNs don't require any special kind of VPN client software to be pre-installed on the user's desktop. Of course, the user does need some software, like an SSL-enabled web browser, typically with either Java or ActiveX enabled; and the user probably already has these things installed from an initial desktop installation.

There are three general types of SSL client implementations:

• Clientless
• Thin client
• Network client

Because only a web browser is required on the user's desktop, the SSL VPN client is commonly referred to as "clientless" (not quite true, of course) or "webified." Therefore, SSL VPNs are sometimes called clientless VPNs or Web VPNs when only a web browser is used for the SSL VPN. The main drawback of a clientless VPN is that only web-based traffic can be protected.

A thin client typically is Java or ActiveX software downloaded via the SSL VPN to the user's desktop. It allows a small subset of non-web applications to be transported across the SSL VPN. The process of transporting non-web applications across an SSL VPN is sometimes referred to as "port forwarding." The initial Cisco WebVPN implementation supported this feature.

For network-based access, an SSL client is required to be installed on the user's desktop; however, this typically is downloaded dynamically to the user's desktop when he establishes the initial SSL VPN to the central site. With network-based access, most network-layer traffic can be protected by the SSL VPN, which is similar to what other network-based VPN implementations do. Because an SSL client needs to be installed to provide network-level protection, the user must have administrative rights on the PC he is using; without administrative rights, the user will be restricted to a thin client or clientless connection, depending on the vendor's SSL VPN implementation.

Tip

Because the network-based SSL client typically requires the user to have administrative rights to install and use the client, a thin client might be a better solution, because a thin client can be developed with Java or ActiveX code that can be downloaded to the web browser during the initial SSL VPN connection. However, the number of non-web applications supported will be limited. For thin client support, I would definitely scrutinize the non-web applications a vendor supports before choosing a solution.

 

SSL Protection

In the next few sections I'll discuss some of the features of SSL VPNs: how they provide protection for traffic, methods of authentication and encryption, and content access control. If you recall from Chapter 3, "IPsec," and Chapter 4, "PPTP and L2TP," these VPN implementations provide network-layer (Layer-3) protection. IPsec provides protection for all kinds of IP traffic, whereas the other two, because they use PPP, can provide protection for multiple network-layer protocols.

SSL VPNs don't necessarily provide network-layer protection of data, as IPsec, PPTP, and L2TP do. Clientless SSL VPNs provide session layer protection (Layer-5) for a web-based application that uses a web browser. Therefore, its use in protecting traffic is somewhat limited; for application traffic to be protected, somehow the user's access to the application must be through a web browser. Of course, any HTTP-type connection can easily be protected because the user uses a web browser for this type of function; but this can present problems for other types of applications, such as Telnet, POP3, SMTP, SNMP, ping, traceroute, FTP, IP telephony, Citrix, Oracle's SQL*net, file and print sharing via Windows or Unix, any many, many others. SSL VPN vendors typically have to write special code in either Java or ActiveX for their VPN gateways to allow non-browser applications to actually use the SSL VPN connection between the user's desktop and the SSL VPN gateway device. This code is typically downloaded dynamically from the SSL VPN gateway to the user's desktop when the user brings up the SSL VPN connection.

I'm constantly asked about the difference between IPsec and SSL VPNs. My answer is always that:

• IPsec provides protection for IP packets and protocols transmitted between networks or hosts.
• SSL VPNs provide protection for users' access to services and applications on a network.

I'll use Figure 5-1 to illustrate the basic difference in the protection that IPsec and SSL VPNs provide for remote access connections.

Figure 5-1. IPsec and SSL VPN Implementations

The top part of Figure 5-1 shows an IPsec remote access VPN. In this example, the IPsec remote access client is an extension of the network on the left-hand side. The remote access client has two addresses: one for communicating to the IPsec gateway and one for communicating to the internal devices (internal address). As you can see from this example, the client's internal address is associated with the internal network and therefore, from the internal network's perspective, it appears that the client is directly connected to this network.

An SSL clientless VPN implementation example is shown in the bottom part of Figure 5-1. In this example, notice that the SSL client doesn't have two addresses and therefore, from the corporate office's perspective, appears to be external to the network. On top of this, only certain applications are supported for this vendor's implementation: web access, webified e-mail server access, and file and print sharing access. The last two applications are vendor-specific and typically require a thin or network-based client; for example, Cisco supports Lotus Notes and port-forwarding of a limited number of non-web applications such as Telnet with their thin client. In the next three sections I'll discuss how SSL VPNs can provide protection and control over your users' traffic.

Note

It's worth noting that the lines between SSL VPNs and network-based solutions, such as IPsec, are blurring. Many SSL VPN vendors are adding network-based support to their implementation; however, this process has a downside. An SSL client either has to be pre-installed on a user's desktop (typically done when the user doesn't have administrative rights on the PC) or dynamically installed when the user brings up the SSL VPN connection.

 

SSL Authentication

Like other VPN implementations, SSL VPNs offer authentication and access control features. If you recall from Chapter 3, IPsec can perform both device and user authentication. Device authentication is handled using pre-shared keys, RSA encrypted nonces, or RSA signatures (digital certificates). User authentication is handled using XAUTH.

In Chapter 4, "PPTP and L2TP," I discussed how these two protocols support authentication: PPTP uses PPP's PAP, CHAP, MS-CHAP, or EAP for user authentication, whereas L2TP/IPsec supports both device and user authentication. L2TP/IPsec supports the same device authentication as IPsec and the same user authentication as PPTP.

SSL VPN implementations typically support two methods of authentication:

• Digital certificates
• Username and passwords (or tokens)

Digital certificates are used to perform device authentication. Some vendors would group both of the above bullets under user authentication; however, I would disagree with this grouping because the certificate is obtained once and stored on the deviceit's not something the user must enter dynamically during the authentication process.

SSL certificates contain information about the user, device, or organization that uses them, including a public key and an encrypted digital signature. The public key can decrypt the information in the signature and use the unencrypted key to validate the integrity of the certificate. Remember that SSL certificates can be:

• Self-generated
• Created by a CA and installed on a device

Caution

If you are concerned about the security surrounding authentication functions, I would not use self-generated certificates, because anyone can create them! Instead, I would use a third-party trust system with a CA acting as the trusted third party. Another issue with SSL is that by default, only the server-end (the SSL VPN gateway) has to authenticate to the user; you definitely will want to implement two-way authentication when using certificates. Even though digital certificate authentication of user devices is possible, it is not very common today. The most common authentication deployment solution today is to use a CA to create certificates for SSL VPN gateways and to combine this with user authentication, where the password is either static or a one-time password (OTP) via a token card.

 

SSL Encryption

Netscape originally developed SSL to encrypt traffic between two devices. SSL's latest version is version 3 (SSLv3), which was released in 1996. SSL supports RC4, DES, and 3DES encryption. Later, IETF created a draft standard based on SSL, called Transport Layer Security (TLS). TLS 1.0 (TLSv1) is defined in RFC 2246.

Here are some other RFCs for TLS:

• RFC 2712 adds 40-bit encryption to TLS.
• RFC 2817 allows secured and unsecured traffic over an HTTPS connection (port 443) for TLS.
• RFC 2828 allows HTTP over TLS to operate on a different server port than 443.
• RFC 3268 adds AES to TLS's support for encryption algorithms, which also include RC2, RC4, IDEA, DES, and 3DES.

Both SSL and TLS are supported in most web browser products today, including Microsoft Internet Explorer and Netscape Navigator; of the two, TLS provides for stronger security and encryption.

Note

Throughout this chapter and the rest of the book, whenever I refer to SSL VPNs, I'm also including TLS.

 

SSL Content Control

One advantage of clientless/thin client SSL VPNs is that you have more granular access over the applications than a user can use on the SSL connection, because for many of these applications, you must configure them on your SSL gateway device to allow access to them. Therefore, if you're interested in controlling access to either specific applications or specific web sites, an SSL VPN is a better solution than a Layer-3 VPN implementation that allows all traffic across the VPN by default. Of course, you could always configure a packet filter for the Layer-3 VPN remote access client, but this can be a management headache in a large network with a large number of remote access clients with different access needs.

SSL VPNs allow a more granular access control method. The SSL VPN client initially opens a web page to the VPN gateway. The web page has a list of links for the user to access other locations. In this sense, the VPN gateway acts as a proxy device. You, the administrator, control what appears on the SSL gateway's initial web page and, therefore, control what resources behind the SSL gateway users can access. Some vendors' solutions go into even more depth than this when it comes to access control; with some products, you can even implement content-based filtering.

Note

The Cisco SSL VPN implementation does not support content filtering; however, you can easily use one of the other content filtering solutions to accomplish this task.

 

SSL Components

Now that I've talked briefly about what SSL VPNs are, let's talk about the two components in an SSL VPN implementation:

• SSL Client
• SSL Gateway

The next two sections will discuss these components.

SSL Client

When choosing a VPN implementation for a VPN solution, one question asked is: "Should I use a solution with a client or one that is clientless?" One original eye-catching thing about clientless and thin client SSL VPNs is that they use a standard web browser rather than having to install VPN client software on each remote access user's desktop. However, the choice is not as simple as this sounds.

Web- and Non-Web-Based Applications

SSL VPNs are best suited if your user's applications are, for the most part, web browser-based. If you have a mixture of applications where many of them are not web browser-based, the SSL VPN solution might not be able to support one, some, or all of these applications.

Non-web browser-based applications have to be webified to work with a clientless or thin client SSL VPN. Every vendor that I've dealt with concerning thin client Web VPNs has used either Java or ActiveX code on their SSL VPN gateway to tunnel non-web browser-based applications across the SSL tunnel: this can be done via a thin client or a network client. The applications supported for a thin client or the protocols supported for a network client are vendor-dependent.

Another issue with this process is that a thin client will have to download Java or ActiveX code for each non-web browser-based application it wants to use, such as Windows Terminal Server, Citrix, and others. Moreover, these applets and controls might conflict with the client's web browser security policy concerning the downloading and execution of applets and scripts. For example, some companies automatically have web browsers block all unsigned Java and ActiveX code, assuming that these might be Trojan horse attacks. Therefore, you might have to have your users change this policy on their desktops to allow unsigned applets and controls, which is a security risk in and of itself. To alleviate this problem, all SSL VPN vendors will sign their Java or ActiveX code to allow them to function correctly, in most instances.

Generally, the Java or ActiveX code that is downloaded to the user's desktop is not specific to an application. It provides access to many different protocols or ports over a single application, such as a web browser. The main question about the code that is downloaded is whether it implements a thin or network client implementation.

Given these problems, this is where a Layer-3 VPN implementation, such as IPsec, shines, because Layer-3 VPN implementations can protect all application layer traffic for a particular protocol. In other words, once you've decided that you need to protect all network-layer traffic, the strongest benefits of SSL VPNs begin to vanish in favor of a traditional Layer-3 VPN solution like IPsec, PPTP, or L2TP/IPsec.

SSL Client Security

One major concern about SSL VPNs using a clientless or thin client implementation is that not all traffic to and from the client is protected, thereby leaving the client open to attack: in other words, unlike an IPsec client that might require all traffic to be tunneled (split tunneling is disabled), a user's web browser will allow a user to access any web site on the Internet. With an SSL VPN, only tunneled traffic can be protected. If a user's desktop is compromised, the attacker has a secure connection to your company.

Therefore, if you decide to use a clientless or thin client SSL VPN implementation, your security policy should contain a statement requiring all SSL remote access clients to have, at a minimum, personal software firewalls installed, and more preferably host IDS software, such as Cisco Host IPS or Cisco Security Agent (CSA).

SSL network clients typically add security enhancements to deal with some of these problems. For example, Cisco Secure Desktop (CSD), available on the Cisco 3000 VPN concentrators running 4.7, allows you to require a personal firewall or antivirus software to be installed before the SSL session can be established successfully. Of course, making these requirements will work only when the corporation has rights to access the user's desktop; for users making connections from non-corporate PCs, implementing these safeguards typically is not possible (like at an airport kiosk or an Internet café).

Some vendors' SSL implementations include some safeguards like the following:

• Upon SSL tunnel termination, the SSL client deletes all traces of the SSL tunnel activity, such as cached credentials and web pages, temporary files, and cookies. Incidental tunnel terminations can be detected through the use of idle timeouts or keepalives. For example, CSD encrypts all data created during the duration of the SSL session and ensures that it is non-recoverable at the end of the session.
• The VPN gateway can run an applet or control to check for the existence and operation of a firewall, anti-virus, or anti-spyware software. Cisco implements this with CSD.
• The VPN gateway can implement access control rules to control what applications, and operations within those applications, are allowed.

All of these enhancements, though, are vendor-dependent.

The same security issues can be said to apply to Layer-3 VPN implementations with software clients; however, many of them have the ability to control the traffic that is protected (split tunneling) and some have enhanced features to enforce the use of firewalls. If you're concerned about exposing a user's desktop to outside threats, you could disable split tunneling, requiring all traffic to be sent protected to the VPN gateway. Some vendors' Layer-3 VPN clients even include firewall solutions, such as the Cisco VPN Client, Check Point'sVPN-1, and WatchGuard's Mobile User VPN clients.

Brief Overview of SSL Clients

Your choice when dealing with clients comes down to two sets of issues:

• With SSL VPNs, you'll probably have to customize the VPN gateway to support additional non-web browser applications, if this is at all possible; however, the upside is that your users probably will need minimal training, if any, to use a Web VPN solution because they already should be familiar with the use of a web browser. Plus, any necessary software to implement this function for port forwarding of non-web applications or network-based protection typically is downloaded dynamically from the SSL gateway to the user's desktop when the SSL VPN connection is initiated. Optionally, a Layer-3 SSL client can be downloaded and installed on the user's desktop, but this requires administrative rights on the desktop.
• With Layer-3 VPN implementations, such as IPsec, you must install and maintain a software client on each user's desktop. This will require additional training for your users on how to use the VPN client software. The advantage of Layer-3 VPN clients is that users can use their native applications without any special configuration by the VPN software. Of course, if you're concerned about putting a client on a user's desktop and having to manage this, you could always opt for a hardware client solution, which is, for the most part, transparent to the user, or a network-based SSL solution, which typically will be able to protect most of the user's traffic, but might not support split-tunneling policies. In the latter case, you wouldn't be able to protect all traffic to and from the user's PC.

Gateway

One of the key components to consider when choosing a VPN implementation is the product you'll use as a VPN gatewaythis seemingly simple choice can make the implementation process a nightmare or an easy process. For example, if you'll be implementing an IPsec VPN, here are some of the criteria to consider when choosing a gateway product:

• Assigning addressing and policy information to the remote access clients; the more options, the more flexible the solution
• Flexibility in defining protected and unprotected traffic (split tunneling)
• Handling routing issues with reaching remote access clients connected to different VPN gateways
• Implementing access control policies for the remote access users

SSL VPNs have different requirements than a Layer-3 VPN implementation. For example, you don't need to assign any addresses to SSL clientless or thin clients, and routing shouldn't be a problem because the client is known via one address, which typically is a public address. With SSL VPNs, you should be asking the following questions concerning SSL gateway products:

• Can you integrate authentication functions with directory services to simplify access control, providing a single-login function?
• What non-web-based applications can be tunneled through the SSL VPN?
• Can you filter access content, for example, what web sites a user can access or what content they can download?