When to Use SSL VPNs

Now that you have a basic understanding of the operation and use of SSL VPNs, I'll discuss when SSL VPNs make sense. Normally, I would consider using clientless SSL VPNs when some or all of the following are true:

• Users use a web browser to access and interact with their applications.
• Users need to access only a very limited number of company resources and not a wide range of hosts and services.
• As an administrator, you have very little or no control over the user's desktop and the software that is or isn't installed on it.
• Users need only occasional access to the network, where sometimes this access is not from their PC but a public device such as an unmanaged PC (PC at an Internet café or an airport or library kiosk).

If you have a small number of non-web applications, in addition to web applications, that you want to protect to a central site, using a thin client SSL VPN would be a good solution; however, you'll need to ensure that for the non-web applications you want to tunnel, the list of vendors you're examining support these.

If you're interested in reducing the amount of management you'll need to perform on a user's desktop but want to be able to protect network-level traffic to the corporate site, I might consider a network SSL VPN. One main disadvantage of this solution, though, is that you might not be able to implement any type of split tunneling policies, and thus the user might be able to access resources from his PC in clear text.

The following two sections discuss the advantages and disadvantages of SSL VPNs, followed by a quick comparison between SSL VPNs and IPsec VPNs.

Advantages of SSL VPNs

SSL VPNs are ideal for those users who use web browsers on a daily basis for interacting with a company's applications. Here is a brief list of the advantages of SSL VPNs:

• No additional software typically needs to be installed on the users' desktops.
• You can access applications securely from anywhere; you only need a device with a web browser.
• A wide variety of web browsers are usually supported.
• Little training is required for your users.
• Users typically can be authenticated by several methods, including static passwords, certificates, directory services, and token card solutions. With directory services, a single login process authenticates the user to the SSL gateway in addition to authenticating to the directory service.
• SSL VPNs work with address translation because SSL/TLS uses TCP, and only the TCP payload is protected. Because SSL provides protection for the payload in the TCP segment, and not the outer TCP segment header, SSL VPN traffic can traverse NAT or PAT devices. This is one headache of most Layer-3 VPN implementations; their data tunnels typically are Layer-3 tunnels. Sometimes NAT works for Layer-3 VPNs, but PAT breaks the tunnel connection. Of course, as I mentioned in Chapters 3 and 4, there are ways of getting around this problem for Layer-3 VPN solutions; however, these add more overhead and make the Layer-3 VPN solution less efficient than a clientless SSL VPN. However, if you'll be using a thin or network client, the amount of overhead to tunnel traffic is comparable to IPsec.

Disadvantages of SSL VPNs

Given their advantages, SSL VPNs do have their limitations and disadvantages. This section will explore a few of them. Web applications use TCP port 80 for their connections. Encrypted web connections (SSL/TLS) also use TCP, but on a different port: 443. By using TCP, SSL has these two advantages:

• It can detect message replay attacks.
• Its protection is the TCP payload, and therefore SSL VPN traffic can traverse a NAT or PAT device.

SSL uses the TCP sequence numbers to detect and drop message replay attacks. Even though it can perform this function, Layer-3 VPNs, like IPsec, actually do this better. IPsec performs this process at Layer-3 while SSL does it at Layer-4. Therefore, IPsec is more efficient since it can detect replay attacks at Layer-3.

TCP has another limiting factor: it is more affected by denial of service (DoS) attacks. For example, with IPsec's management connection, which uses UDP, it is fairly easy to deflect these attacks by examining the digital signature in the UDP packet. However, with SSL and TCP it's worse, because a TCP SYN flood attack would fill up the TCP session table on the device and bring a device to a screeching halt. Therefore, you might want to consider implementing a solution that can detect and defeat TCP-based DoS attacks. Here are some Cisco solutions that can provide these services:

• Cisco routers with TCP Intercept
• Cisco routers with the IOS Firewall Feature set's Context-Based Access Control
• Cisco PIX and ASA security appliances with FloodGuard

SSL Versus IPsec

Given their advantages and disadvantages, I'll quickly compare SSL VPNs with IPsec so that you have a better understanding as to when to use each solution. Table 5-1 compares these two VPN implementations. This is not to say that your company must choose one over the other; both implementations have strengths and weaknesses. The two can be used in combination to solve specific security problems in your network.

Table 5-1. SSL and IPsec Comparison

Component	SSL	IPsec
Connectivity	SSL only supports remote access	IPsec supports both site-to-site and remote access
Device authentication	SSL supports digital certificates	IPsec supports pre-shared keys, RSA encrypted nonces, and digital certificates
User authentication	SSL supports user authentication	IPsec supports user authentication through XAUTH unless it's L2TP/IPsec, in which case it's L2TP that is responsible for user authentication
Protection	SSL protects only the TCP payload and is thus susceptible to certain kinds of attacks	IPsec can protect the user's data in a transport connection or an entire IP packet in tunnel mode
Encryption	SSL/TLS support RC2, RC4, IDEA, DES, 3DES, and AES; however most web browsers only support RC4, DES, and 3DES	IPsec supports DES, 3DES, and AES
Message integrity	SSL supports none except that provided by TCP	IPsec supports MD5 and SHA-1 HMAC functions
Implementation requirements	SSL requires a web browser with Java/ActiveX installed for thin and network clients; because a web browser is used, most user operating systems will be supported	IPsec requires an IPsec client installed or built into the operating system and configured on each user's desktop; because a special client must be installed, only operating systems supported by the vendor can use IPsec
Transparency	SSL has no problem with a session traversing an address translation device (NAT and/or PAT)	IPsec has problems with AH traversing through any type of address translation device and ESP traversing a PAT device; however, IPsec is more likely to be denied by a firewall than a TCP port 443 (SSL) connection
ISP issues	Because SSL is commonly used on the Internet, ISPs don't block this kind of traffic	Some ISPs block IPsec traffic and require users to pay an additional fee to use IPsec; you can get around this problem by encapsulating IPsec data in either a TCP or UDP segment, but this adds overhead to the transmission; this assumes that this process doesn't break the ISP's acceptable use policy (AUP)

The main advantage of clientless SSL VPNs is that users can use any machine with a web browser installed. For thin clients or network clients, Java/ActiveX will need to be installed to access the corporate network securely; this probably has already been done for the user to successfully navigate many web sites on the Internet. Because a PC typically has both a web browser and Java or ActiveX installed, SSL VPNs are ideal for mobile users who might be using different devices at different locations to gain access to your network, for example, another company's PC or an airport kiosk. For the traveling salesperson accessing the corporate network from non-corporate devices, SSL VPNs are ideal.

The downside of clientless or thin client SSL VPNs is that they support only a limited number of applications. Therefore, for users who need secure access to these services, or for users who always will be accessing the company's network from a fixed device, IPsec or, possibly, network client SSL VPNs, would be a better fit (IPsec is typically a better option). And of course, if you have both types of users with these different needs, one set can use an SSL solution and the other an IPsec one! This could be applied to the same user, depending upon where the user is connecting from. As I've pointed out to many customers who have queried me on this topic, it's not that one solution is right or wrong, or better or worse than the other . . . a company's specific situation will determine whether one, the other, or both are used to provide for secure connectivity.

Note

I'd like to point out that IPv6 standard actually includes IPsec as part of its implementation. Even though it's part of the IPv6 implementation, IPsec is optional. However, because it is a component directly built into IPv6, and if IPv6 would eventually be deployed down to the user desktop, SSL (and SSL VPNs) would no longer be necessary.

My Experiences with SSL VPNs

I've had mixed success with SSL VPN implementations. Most SSL VPN implementations offered by vendors are still in their infancy stage and therefore some types of non-web browser-based applications or protocols will work and some won'teven if the vendor says they're supposed to work. For example, I once had an SSL vendor say that they supported Citrix through a port forwarding function. I bought two SSL gateways from them specifically for this function; however, once I installed them, for the life of me, I could never get the Citrix connectivity to work through the SSL VPN. I contacted their support team and they told me that since they had added this feature, it was hit-and-miss about it working. Apparently there were a lot of bugs in the software that they needed to weed out. Of course I returned the two SSL VPN gateways and got my customer's money back. From this and other SSL VPN experiences, I've learned that if a customer needs a specific application to work with SSL VPNs, I'll have the vendor actually prove it with a test unit before investing a lot of time, effort, and money into the process.