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:
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:
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:
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:
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.
SSL only supports remote access
IPsec supports both site-to-site and remote access
SSL supports digital certificates
IPsec supports pre-shared keys, RSA encrypted nonces, and digital certificates
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
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
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
SSL supports none except that provided by TCP
IPsec supports MD5 and SHA-1 HMAC functions
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
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
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.
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.
Part I: VPNs
Overview of VPNs
PPTP and L2TP
Part II: Concentrators
Concentrator Product Information
Concentrator Remote Access Connections with IPsec
Concentrator Remote Access Connections with PPTP, L2TP, and WebVPN
Concentrator Site-to-Site Connections
Verifying and Troubleshooting Concentrator Connections
Part III: Clients
Cisco VPN Software Client
Windows Software Client
3002 Hardware Client
Part IV: IOS Routers
Router Product Information
Router ISAKMP/IKE Phase 1 Connectivity
Router Site-to-Site Connections
Router Remote Access Connections
Troubleshooting Router Connections
Part V: PIX Firewalls
PIX and ASA Product Information
PIX and ASA Site-to-Site Connections
PIX and ASA Remote Access Connections
Troubleshooting PIX and ASA Connections
Part VI: Case Study