Chapter 10: Designing and Building SSL Remote Access VPNs (WebVPN)

Cisco Press

By Mark Lewis, Network World
July 25, 2007 03:05 PM ET

. What's this?

More Cisco Press book chapters from new and classic Cisco Press books.

Rate your favorite Cisco Press books.

Providing remote access VPN connectivity is a relatively new application for the Secure Sockets Layer (SSL). SSL was designed to secure TCP-based protocols and applications such as HTTP (HTTPS), FTP (FTPS), POP3 (POP3S), and SMTP (SMTPS).

SSL is built in to most, if not all, web browsers, and this fact allows the deployment of SSL remote access VPNs without the requirement to install specific client software on remote user workstations or devices—only a web browser is needed for basic (clientless) SSL remote access VPN connectivity.

Although clientless SSL remote access VPNs provide a basic level of access, more comprehensive access can be provided through the use of the Cisco SSL VPN Client. This software provides users with remote access VPN connectivity that is comparable to that provided by IPsec or Layer Two Tunneling Protocol (L2TP)/IPsec.

Figure 10-1 illustrates SSL remote access VPNs.

Figure 10-1
SSL Remote Access VPNs

In Figure 10-1, remote access users at an Internet caf , airport Internet kiosk, and a hotel access the corporate network using variously HTTPS, POP3S, SMTPS, and port forwarding (TCP-based application traffic redirected over SSL). A telecommuter accesses the corporate network using the Cisco SSL VPN Client.

In this chapter, you will learn how SSL remote access VPNs compare to other types of remote access VPN. You will also find out the characteristics of SSL remote access VPNs, as well as how to design and implement them to provide exactly the type and level of functionality required.

Finally, you will learn how to properly secure SSL remote access VPNs—a very important consideration, particularly when users may be accessing the corporate network from untrusted locations such as Internet cafes and airport kiosks.

Comparing SSL VPNs to Other Types of Remote Access VPNs

When deciding whether to implement SSL remote access VPNs, it is essential to understand how they compare to other types of remote access VPNs and what their advantages and disadvantages are.

Some of the main advantages and disadvantages of SSL remote access VPNs are as follows:

SSL remote access VPNs are relatively simple to deploy because it is not necessary to install or administer a VPN client on remote user devices.
It is only necessary for remote user devices to have a web browser to access the corporate network. Remote users can use a web browser to access corporate networks from a wide variety of locations, including Internet cafes and airport Internet kiosks.
Clientless SSL remote access VPNs (those accessed using a web browser) provide a subset of the functionality provided by IPsec or L2TP/IPsec remote access VPNs.
SSL remote access VPN functionality can be enhanced by configuring the VPN gateway to dynamically download an SSL VPN client to remote user devices.
SSL VPNs can impose a relatively high CPU overhead on a VPN gateway if there are a large number of remote access users. This is due to the high CPU overhead incurred by public key operations associated with SSL.

The relatively high CPU overhead imposed by SSL remote access VPNs can be ameliorated by careful selection of SSL remote access VPN gateways.
Little configuration is required on firewalls and NAT devices to provide transit for SSL remote access VPN traffic because SSL is carried over (NAT-friendly) TCP.
Typically, TCP ports 443 (HTTPS) as well as (if e-mail proxy is configured) ports used for POP3 over SSL (POP3S), IMAP4 over SSL (IMAP4S), and SMTP over SSL (SMTPS) need to be opened for firewalls to ensure correct operation of SSL remote access VPNs.
One major disadvantage of SSL remote access VPN has been that universal access that they offer can lead to vulnerabilities being introduced into a corporate network. This is due to the untrusted nature of locations/workstations from which users can connect (Internet cafes, kiosks, hotels, and so on).
Cisco addresses these concerns with the Cisco Secure Desktop.

Now that you understand the advantages and disadvantages of SSL VPNs, it is time to move on to their operation, design, and implementation.

Understanding the Operation of SSL Remote Access VPNs

Before getting into the design and implementation of SSL remote access VPNs, it is a very good idea to take a look at the underlying mechanisms that allow their operation. This section examines the protocols and mechanisms are used to enable SSL remote accessVPNs.

The Secure Sockets Layer (SSL) is a security protocol that is used to secure e-commerce, web transactions, and more recently, to provide remote access VPN connectivity.

SSL was invented by Netscape Communications, and there are a number of versions:

SSL version 1 (SSLv1)—This version was not released by Netscape.
SSL version 2 (SSLv2)—This version was released and is still supported by many web browsers, but it has a number of well-known weaknesses and deficiencies, including its vulnerability to downgrade attacks (an attacker can force the negotiation of a weak cipher suite [which is then subject to attack]); its vulnerability to truncation attacks (an attacker can cause either the server or the client to believe that data transfer has finished by simply forging a TCP FIN); the fact that SSLv2 relies on MD5 MACs and SHA-1 is not available for use; the fact that the same key is used for encryption and authentication (so breaking the key of one leads automatically to the breaking of the other); and the ability of an attacker to intercept and hijack a client's connection. So, SSLv2 is definitely not recommended.
SSL version 3 (SSLv3)—This version addresses the weaknesses of SSLv2.
Transport Layer Security (TLS version 1.0, RFC 2246)—This is an IETF standard that is based on but not compatible with SSLv3.

In this chapter, the term SSL is used as a generic term to describe SSLv3 and TLS.

SSL Overview: TCP, the Record Layer, and the Handshake Protocol

SSL sits on top of a reliable protocol, such as TCP. Application data can then be carried on top of SSL.

Figure 10-2 shows the overall SSL packet format.

Figure 10-2
Overall SSL Packet Format

The SSL protocol itself consists of the record protocol plus the handshake protocol, the alert protocol, the change cipher spec protocol, and the application data protocol.

Figure 10-3 shows the relationship between the record protocol and the handshake, alert, change cipher spec, and application data protocols.

The Record layer (protocol) has a number of functions, including the following:

Fragmentation—The record protocol fragments/reassembles data on transmission/reception, if required.
Compression—If negotiated between a client and server, the record protocol compresses/decompresses data.
Applies MAC—The record protocol applies/verifies a MAC.
Encryption—The record protocol encrypts/decrypts data.

Figure 10-3
Relationship Between the Record Protocol and the Handshake, Alert, Change Cipher Spec, and Application Data Protocols

As shown in Figure 10-3, the handshake, alert, change cipher spec, and application data protocols sit on top of the Record layer. These protocols have the following functions:

Handshake protocol (type 22)—This protocol consists of a number of messages exchanged between peers (the client and server) that allow those peers to negotiate SSL version, cryptographic algorithms, and parameters; optionally authenticate each other; and generate shared secret cryptographic keys using public key techniques.

Table 10-1 summarizes SSLv3 and TLS handshake protocol messages.

Table 10-1 Handshake Protocol Messages

Handshake Protocol Message	Type	Sent By	Description
HelloRequest	0	Server	Notification that the client should begin negotiation again.
ClientHello	1	Client	Used to (re-)initiate an SSL connection. Specifies list of cryptographic algorithms/parameters, plus optional compression method and random number.
ServerHello	2	Server	Specifies chosen cryptographic algorithms/parameters and optional compression method. Includes random number.
Certificate	11	Client/server	Contains certificate or certificate chain.
ServerKeyExchange	12	Server	Used in ephemeral RSA or Diffie-Hellman handshake when server certificate message does not allow client to exchange premaster secret.
CertificateRequest	13	Server	Used by the server to request the client's certificate. Used when client authentication is required.
ServerHelloDone	14	Server	Used to indicate that the server will not send any more messages at this stage of the handshake.
CertificateVerify	15	Client	Used by the client to prove that it is the legitimate owner of its certificate.
ClientKeyExchange	16	Client	Used to send the premaster secret to the server.
Finished	20	Client/server	Ensures integrity of handshake exchange.

Alert protocol (type 21)—This is used to signal error conditions. These error conditions include those that occur during an SSL handshake, when decrypting or integrity checking, or when closing a connection.
Change cipher spec protocol (type 20)—This protocol (which consists of a single message type) is used by the client or server to signal that subsequent SSL messages will be protected using negotiated cryptographic algorithms, parameters, and keys.
Application data protocol (type 23)—The application data protocol carries data from whichever application or applications are running over SSL. This data can include protocols such as HTTP, FTP, POP3, IMAP4, SMTP, as well as other higher-level protocol data.