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.
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.
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.
Establishing an SSL Connection Between a Remote Access VPN User and an SSL VPN Gateway Using an RSA Handshake
As previously described, the function of SSL is to negotiate cryptographic algorithms, authenticate the server (VPN gateway) and optionally the remote access VPN client, and establish cryptographic keys.
The most common method of establishing an SSL connection between a remote access VPN client and a VPN gateway is using the Rivest, Shamir, and Addlemen (RSA) handshake with VPN gateway authentication. In this case, the remote access VPN client is not authenticated during the handshake, but may be authenticated using a separate mechanism after the SSL connection has been established.
Figure 10-4 illustrates the RSA handshake with VPN gateway only authentication.
SSL RSA Handshake
As shown in Figure 10-4, the RSA handshake with VPN gateway only authentication consists of the exchange of nine messages:
The first step in the RSA handshake is when the remote access client sends a ClientHello message to the VPN gateway (server). This message is used to propose a number of cryptographic parameters and algorithms (cipher suites), compression methods (if any), and well as being used to transmit a random number that is later used to generate cryptographic keys.
The VPN gateway now selects one of the cryptographic proposals (cipher suites), together with any compression method sent in the ClientHello and includes these chosen proposals in the ServerHello message that it sends to the remote access client.
The ServerHello message also includes a random number generated by the VPN gateway, which is again used to later generate cryptographic keys.
Next, the VPN gateway's sends a Certificate message. This message contains the VPN gateway's certificate (including its public key) along with any other certificates in a certificate chain.
Immediately after the Certificate message is ServerHelloDone. The VPN gateway sends this message to signal that it will not send any more messages at this stage of the handshake sequence.
The remote access client now sends the ClientKeyExchange message. This message includes a key, called the pre_master_secret, which is encrypted using the VPN gateway's public key.
The pre_master_secret, together with the random numbers sent in the ClientHello and ServerHello messages is used to generate the keys later used to encrypt and authenticate SSL traffic.
The ClientKeyExchange message is followed by the ChangeCipherSpec and Finished messages.
The ChangeCipherSpec message signals that SSL messages from the client (starting with the Finished message) will from now on be protected using the negotiated cipher suite.
The Finished message contains a hash of all the messages previously sent in the handshake—this ensures that an attacker has not modified any of the previous handshake messages.
The VPN gateway now completes the RSA handshake by sending its own ChangeCipherSpec and Finished messages.
Now that you know what happens in theory, it is time to take a look at an SSL connection in practice.
SSL Connection Establishment: ClientHello Message
Figure 10-5 shows a packet capture of an SSL ClientHello message.
SSL ClientHello Message
If you look at the highlighted line in the main portion of the screen shown in Figure 10-5, you can see the message is, in fact, a ClientHello message. Below the highlighted line there are a number of message fields that can be described as follows: