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

Cisco Press

1 2 3 4 5 6 7 8 Page 2
Page 2 of 8
  • Record layer header:

  • Content Type—This field specifies the record type, which in this case is Handshake (type 22).

    Version—This defines the SSL version (major and minor versions). SSLv3 is 3.0 (0x0300), and TLS is 3.1 (0x0301).

    Length—The 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 protocol header:

  • Handshake Type—The handshake protocol message type. Here, the message type is ClientHello (1).

    Length—The length of the message.

    Version—The 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 Length—The 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 Length—The length of the Cipher Suites list.

  • Cipher Suites—There are a number of SSL cipher suites, including a number that require the VPN gateway to provide an RSA certificate, a number that are used for server authenticated (and optionally client authenticated) Diffie-Hellman, and a number that are used for anonymous Diffie-Hellman communications where neither the VPN gateway nor the client is authenticated.

  • 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 Length—The length of the Compression Methods field.

    Compression Methods—This 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.06

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:

  • The Handshake Type field now specifies that this message is a ServerHello (2).

  • The Session ID Length field specifies a 32-byte length.

  • The Session ID field specifies a Session ID that can be used to resume the session at a later stage if desired.

  • The Cipher Suite field specifies the cipher suite chosen by the VPN gateway from those sent by the client in the ClientHello message.

Immediately after the ServerHello is the Certificate message. The Certificate message is relatively simple and consists of the following fields:

  • Handshake Type—In this case, this field is used to specify that this is a certificate message (11).

  • Length—The length of this message.

  • Certificates Length—The length of the certificate(s) included in this message.

  • Certificates—The certificate or certificates sent by the VPN gateway, including the following:

  • Certificate Length—The length of this certificate.

    Certificate—The 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:

  • Handshake Type—The type of handshake message, which is ServerHelloDone (14).

  • Length—The length of the message, which in this case is zero (remember that ServerHelloDone simply indicates that the VPN gateway does not have any more messages to send at this stage).

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.07

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:

  • The common Record layer header, including the following

  • 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.

  • A ClientKeyExchange message, including the following

  • Handshake Type—This is a ClientKeyExchange message (16).

    Length—This message is 130 bytes long.

  • A ChangeCipherSpec message, including the following

  • Content Type—This is a ChangeCipherSpec message (20).

    Version—This is a TLS message.

    Length—The length of this message is 1 byte.

  • An encrypted Finished message ("Encrypted Handshake Message").

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.08

Figure 10-8

ChangeCipherSpec Message Sent by the Client

Figure 10-9 shows the Finished message sent by the client.

figure 10.09

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-9—this 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 it—the 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.

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.10

Figure 10-10

Application Data Sent over the SSL Connection

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 anomaly—the 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 respectively—note 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.


Note - SSLv3 and TLS (RFC2246) also include a variation on the regular RSA handshake called an ephemeral RSA, 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

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:

  • In response to the ClientHello, the VPN gateway sends a CertificateRequest message in addition to the ServerHello, Certificate, and ServerHelloDone messages.

  • 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 client replies with Certificate and CertificateVerify messages in addition to the ClientKeyExchange, ChangeCipherSpec, and Finished messages.

  • 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.

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.

figure 10.13

Figure 10-13

Resuming an SSL Session

As you can see in Figure 10-13, to resume an SSL session, the follows happens:

  1. The client sends a ClientHello message.

  2. This message has the same format as that shown in Figure 10-5, with the difference that a Session ID field is included (the Session ID Length field is nonzero).

  3. 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.

  4. 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

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 unresumable—this prevents truncation attacks, where an attacker inserts a TCP FIN into the traffic stream between the client and VPN gateway.

Using Clientless SSL Remote Access VPNs (WebVPN) on the Cisco VPN 3000 Concentrator

As discussed at the beginning of this chapter, one great advantage of SSL VPNs is that they do not require dedicated client software—the only software that is required is a standard web browser and e-mail software such as Microsoft Outlook Express, if e-mail functionality is required via POP3/IMAP4/SMTP.

This section examines how it is possible to provide file server access, website access, and TCP application access using clientless SSL remote access VPNs. Before enabling these types of access of SSL, however, it is necessary to complete basic SSL remote access VPN configuration tasks on the VPN 3000 concentrator.

Completing Basic SSL Remote Access VPN Access Configuration Tasks on the Cisco VPN 3000 Concentrator

Before you can enable SSL remote access VPN functionality such as file access or port forwarding, it is necessary to complete a number of basic configuration tasks:

Step 1 Enroll and obtain a (SSL) certificate for the VPN 3000 concentrator from a certificate authority (CA) (optional).

Step 2 Enable WebVPN for relevant user groups (or create a group specifically for WebVPN access).

Step 3 Specify acceptable versions of SSL and configure cryptographic algorithms associated with SSL cipher suites.

Step 4 Enable SSL on the VPN 3000 concentrator's public interface.

The sections that follow describe these steps in further detail. Before moving on to step 1, however, it is worth mentioning that on the Cisco VPN 3000 concentrator, WebVPN uses global DNS settings rather than those specified under a group. So, make sure that you specify global DNS settings under Configuration > System > Servers > DNS.

Step 1: Enroll and Obtain a (SSL) Certificate for the VPN 3000 Concentrator from a Certificate Authority (Optional)

As described earlier in this chapter, clients authenticate the VPN gateway during the RSA handshake using the VPN gateway's certificate (or certificate chain).

Related:
1 2 3 4 5 6 7 8 Page 2
Page 2 of 8
SD-WAN buyers guide: Key questions to ask vendors (and yourself)