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.
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:
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.
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.
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:
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.
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.
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 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:
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.
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:
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.
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.
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.
Now that I've talked briefly about what SSL VPNs are, let's talk about the two components in an SSL VPN implementation:
The next two sections will discuss these components.
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:
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:
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:
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: