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:
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.
Figure 10-3. 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:
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:
Table 10-1 summarizes SSLv3 and TLS handshake protocol messages.
Handshake Protocol Message
Notification that the client should begin negotiation again.
Used to (re-)initiate an SSL connection. Specifies list of cryptographic algorithms/parameters, plus optional compression method and random number.
Specifies chosen cryptographic algorithms/parameters and optional compression method. Includes random number.
Contains certificate or certificate chain.
Used in ephemeral RSA or Diffie-Hellman handshake when server certificate message does not allow client to exchange premaster secret.
Used by the server to request the client's certificate. Used when client authentication is required.
Used to indicate that the server will not send any more messages at this stage of the handshake.
Used by the client to prove that it is the legitimate owner of its certificate.
Used to send the premaster secret to the server.
Ensures integrity of handshake exchange.
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.
Figure 10-4. 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 ServerHello message also includes a random number generated by the VPN gateway, which is again used to later generate cryptographic keys.
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 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 handshakethis ensures that an attacker has not modified any of the previous handshake 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.
Figure 10-5. 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:
- Content TypeThis field specifies the record type, which in this case is Handshake (type 22).
- VersionThis defines the SSL version (major and minor versions). SSLv3 is 3.0 (0x0300), and TLS is 3.1 (0x0301).
- LengthThe length of the record. According to the specification, a record can be up to a maximum of 214 bytes, although at least one browser type did erroneously send records of up to 216-1 bytes.
- Handshake TypeThe handshake protocol message type. Here, the message type is ClientHello (1).
- LengthThe length of the message.
- VersionThe highest version of the SSL protocol that the client supports.
- Random number (Random.gmt_unix_time, plus Random.bytes)This is the previously described random number that is later used to generate cryptographic keys.
Notice that the random number is, in fact, made up of the number of seconds since midnight, January 1, 1970 (4 bytes in UNIX format), as well as a 28-byte randomly generated number. The UNIX time is included in the random number to ensure that the same random number is not chosen twice (this would be possible if all 32 bytes of the random number were randomly chosen!).
- Session ID LengthThe length of the Session ID field.
The Session ID length is zero here, and this indicates that the Session ID field itself is not present. The Session ID field is only present in the ClientHello if the client wants to resume a previous SSL session with the VPN gateway.
- Cipher Suites LengthThe length of the Cipher Suites list.
The cipher suites themselves are fairly self-explanatory. For example, TLS_RSA_WITH_RC4_128_MD5 specifies RSA authentication with the RC4 stream cipher for encryption and Message Digest 5 (MD5) for integrity checking. One thing you might notice if you closely examine the cipher suites in Example 10-5 is the lack of any support for AES. This is due to the lack of any AES cipher suites in the base TLS v1.0 specification (RFC 2246 [SSLv3 includes no support for AES, by the way]). RFC 3268 describes support for AES cipher suites with TLS, and this support is integrated into the TLS v1.2 specification, which is under discussion in the IETF TLS working group at the time of this writing. It may be interesting to note that support for AES with HTTPS is added in Microsoft Vista (support is also included in Firefox).
- Compression Methods LengthThe length of the Compression Methods field.
- Compression MethodsThis specifies methods of compression that the client is willing to support. RFC2246 does not specify any compression methods because of intellectual property concerns, and so this client specifies NULL compression, meaning no compression.
Note that RFC3749 does specify the DEFLATE compression algorithm for use with SSL (DEFLATE itself is defined in RFC1951).
SSL Connection Establishment: ServerHello, Certificate, and ServerHelloDone Messages
The next messages in the SSL handshake sequence are ServerHello, Certificate, and ServerHelloDone. The VPN gateway sends these messages (see Figure 10-6).
Figure 10-6. SSL server_hello, Certificate, and ServerHelloDone Messages
If you take a look in the main portion of Figure 10-6, you can see the common SSL record header (Content Type, Version, Length), followed by the ServerHello, Certificate, and ServerHelloDone messages.
The ServerHello message is similar to the ClientHello message, but there are one or two differences:
Immediately after the ServerHello is the Certificate message. The Certificate message is relatively simple and consists of the following fields:
- Certificate LengthThe length of this certificate.
- CertificateThe certificate itself.
Note that a number of certificates can be included.
Next is the ServerHelloDone message. As you can see, it consists of only two fields:
SSL Connection Establishment: ClientKeyExchange, ChangeCipherSpec, and Finished Messages
After the VPN gateway sends the ServerHello, Certificate, and ServerHelloDone messages, the client responds with the ClientKeyExchange, ChangeCipherSpec, and Finished messages.
Figure 10-7 shows the transmission of the ClientKeyExchange, ChangeCipherSpec, and Finished messages. The Finished message is the first in the handshake to be encrypted.
Figure 10-7. Transmission of the ClientKeyExchange, ChangeCipherSpec, and Finished Messages
Figure 10-7 again shows the common Record layer header, followed by the ClientKeyExhange, ChangeCipherSpec, and Finished messages:
- Content Type Specifies that this is a Handshake message (22).
- Version This is a TLS (SSL version 3.1) message.
- Length The length of this message is 134 bytes long.
- Handshake Type This is a ClientKeyExchange message (16).
- Length This message is 130 bytes long.
- Content Type This is a ChangeCipherSpec message (20).
- Version This is a TLS message.
- Length The length of this message is 1 byte.
The remote access client now completes the handshake by sending ChangeCipherSpec and Finished messages.
Figure 10-8 shows the ChangeCipherSpec message sent by the client.
Figure 10-8. ChangeCipherSpec Message Sent by the Client
Figure 10-9 shows the Finished message sent by the client.
Figure 10-9. Finished Message Sent by the Client
The format of the Record layer header has already been described, and so will not be described again here. Notice, however, the final line in the output in the main portion of the screen shown in Figure 10-9this line shows that the Handshake message is encrypted. This should be no surprise, as you will remember that the Finished message is, in fact, the first message that is encrypted in the handshake.
And that is itthe handshake is complete, and the client and VPN gateway are ready to send application data to each other over the SSL connection. Figure 10-10 shows application data sent over the SSL connection.
Figure 10-10. Application Data Sent over the SSL Connection
The Record layer header Content Type field shows that this is an Application Data message. The length of the message is 264 bytes, but the payload is encrypted and so is not shown.
SSL Handshake: SSLv2, SSLv3, or TLS?
Before finishing this section, it is worth pointing one apparent anomaly that is sometimes seen in the SSL handshake (see Figure 10-11).
Figure 10-11. SSL Handshake Anomaly
First, take a look at the upper portion of the screen capture. Look at the SSL messages; you will notice the familiar beginning of the RSA handshake (compare with Figure 10-4). If you are the observant type, you will have noticed one apparent anomalythe TLS handshake begins with an SSLv2 ClientHello message!
Now take a look at the lower portion of the screen and you see the detail of the SSLv2 ClientHello. If you look closely at the fields of the Record header, you will notice that although this is an SSLv2 ClientHello, the Version field in the record header specifies TLS!
What is going on? Well, this is a common method that web browsers/clients use to check whether a server/VPN gateway can support SSLv3 or TLS. This method of checking support for SSLv3 or TLS works because the Version fields in SSLv2 and SSLv3/TLS are interpreted differently (SSLv2 is represented as 0x0002, whereas SSLv3 and TLS are represented as 0x0300 and 0x0301 respectivelynote the difference in the way the high-order and low-order octets are used).
So, if a client sends an SSLv2 ClientHello with the Version field set to TLS (0x0301), and the server/VPN gateway supports TLS, it will parse the SSLv3/TLS version field and identify support for TLS, then respond using TLS handshake messages, as appropriate! A server/VPN gateway that supports only SSLv2, on the other hand, will not identify this as TLS.
SSLv3 and TLS (RFC2246) also include a variation on the regular RSA handshake called an ephemeral RSA1, as well as another type of handshake that takes advantage of the Digital Signature Standard (DSS) and Diffie-Hellman algorithms.
The ephemeral RSA handshake permits SSL connections to be established between export clients (which use weak cipher suites) and U.S. domestic servers (which use strong cipher suites) using a strong key.
The DSS/DH handshake, on the other hand, was designed to overcome any issues with patents on the RSA algorithm.
Since U.S. export controls for strong cryptographic software have been relaxed, the ephemeral RSA handshake has become much less relevant. The patent for the RSA algorithm has now expired, and so the DSS/DH handshake has also become less relevant. For these reasons, neither the ephemeral RSA handshake nor the DSS/DH handshake is discussed in this chapter.
Understanding the SSL RSA Handshake with Client Authentication
The RSA handshake described in the previous section ensures that the server/VPN gateway is authenticated by the client (using the certificate sent by the server in the Certificate message). But, how about if you want the server to authenticate client during the handshake, too? In this case, the SSL handshake with client authentication, illustrated in Figure 10-12, is used.
Figure 10-12. SSL Handshake with Client Authentication
If you compare Figure 10-12 with Figure 10-4, you can see that the handshakes are very similar. There are one or two differences, however:
As the name suggests, the CertificateRequest message is used to request that the client send its certificate (or certificate chain) to the VPN gateway as well as to specify which key types are acceptable (for example, RSA) and the CAs it will accept as issuers of certificates (the client's certificate must be issued by one of these).
The Certificate message contains the client's certificate or certificate chain, and the CertificateVerify message is used by the client to prove that it possesses the private key corresponding to the public key contained in its certificate.
The CertificateVerify message consists of a digital signature (using the private key corresponding to the public key in the certificate). Only the owner of the client's certificate should possess the private key, and so the client is able to prove that it really is the owner of the certificate sent in the certificate message.
So, the client authenticates the VPN gateway using the Certificate that the VPN gateway sends (this is the same as the regular RSA handshake with no client authentication), and the VPN gateway authenticates the client using the Certificate and CertificateVerify messages that the client sends.
Resuming an SSL Session
So far, this chapter has described SSL handshakes that allow the establishment of new SSL sessions. This section describes the resumption of a previous SSL session. Figure 10-13 shows the exchange of SSL messages necessary to resume a previous SSL session.
Figure 10-13. Resuming an SSL Session
You might be wondering why you would want to resume an SSL session instead of just establishing a new one (as described in the previous two sections). The answer is that the public key operations that are necessary when establishing a new session are cryptographically expensive/processor intensive, whereas resuming a previous session does not require these expensive public key operations.
As you can see in Figure 10-13, to resume an SSL session, the follows happens:
The client sends a ClientHello message.
The Session ID in the ClientHello identifies a previous session, and the VPN gateway responds with a ServerHello confirming the resumption of that session, before changing to the previously negotiated cipher suite and ensuring the integrity of the handshake using the ChangeCipherSpec message and Finished messages, respectively.
The client now completes the resumption of the session by sending ChangeCipherSpec and Finished messages. After these messages have been sent, Application Data messages can begin to flow between the client and VPN gateway.
Closing an SSL Connection
The final action in an SSL connection is its closure. This is illustrated in Figure 10-14.
Figure 10-14. SSL Connection Closure
In Figure 10-14, the client initiates connection closure by sending a close_notify Alert message to the VPN gateway. The client then sends a TCP FIN message to terminate the underlying TCP connection.
The VPN gateway responds by sending its own close_notify Alert message, followed by a TCP FIN. The SSL connection is now closed.
Although Figure 10-14 shows the client initiating SSL connection closure, it is possible for either the client or the VPN gateway (server) to initiate connection closure.
Note that if a client or VPN gateway receives a TCP FIN before receiving a close_notify Alert, it marks the connection as being unresumablethis prevents truncation attacks, where an attacker inserts a TCP FIN into the traffic stream between the client and VPN gateway.
Part I: Understanding VPN Technology
What Is a Virtual Private Network?
Part II: Site-to-Site VPNs
Designing and Deploying L2TPv3-Based Layer 2 VPNs
Designing and Implementing AToM-Based Layer 2 VPNs
Designing MPLS Layer 3 Site-to-Site VPNs
Advanced MPLS Layer 3 VPN Deployment Considerations
Deploying Site-to-Site IPsec VPNs
Scaling and Optimizing IPsec VPNs
Part III: Remote Access VPNs
Designing and Implementing L2TPv2 and L2TPv3 Remote Access VPNs
Designing and Deploying IPsec Remote Access and Teleworker VPNs
Designing and Building SSL Remote Access VPNs (WebVPN)
Part IV: Appendixes
Designing and Building SSL Remote Access VPNs (WebVPN)
Appendix B. Answers to Review Questions