Chapter 2: SSL VPN Technology

Cisco Press

1 2 3 4 5 6 7 Page 4
Page 4 of 7
   select (KeyExchangeAlgorithm) {     case rsa: EncryptedPreMasterSecret;     case diffie_hellman: ClientDiffieHellmanPublic;     case fortezza_kea: FortezzaKeys;   } exchange_keys; } ClientKeyExchange;struct {   ProtocolVersion client_version;   opaque random[46]; } PreMasterSecret; struct {   public-key-encrypted PreMasterSecret pre_master_secret; } EncryptedPreMasterSecret; struct {   select (KeyExchangeAlgorithm) {     case rsa: EncryptedPreMasterSecret;     case diffie_hellman: ClientDiffieHellmanPublic;     case fortezza_kea: FortezzaKeys;   } exchange_keys; } ClientKeyExchange;struct {   ProtocolVersion client_version;   opaque random[46]; } PreMasterSecret; struct {   public-key-encrypted PreMasterSecret pre_master_secret; } EncryptedPreMasterSecret;

As you can see from the preceding definition, the pre_master secret has two pieces: the client's offered protocol version and a random number. The protocol version was designed to protect against rollback attacks. The client encrypted the pre_master secret using the server's public key that is retrieved from the server's certificate.

If client authentication is required, the server sends a CertificateRequest message to request that the client send its certificate. The client replies with two messages: the ClientCertificate and CertificateVerify. The ClientCertificate contains the client's certificate, and the CertificateVerify message does the client authentication job. It contains a hash of all the handshake messages so far signed by the client's public key. As discussed earlier in the section on public key algorithms, to authenticate the client, the server retrieves the client's public key from the ClientCertificate, uses the public key to decrypt the received signature, and finally compares the decrypted hash with the hash locally calculated by the server with its own copy of the handshake messages. If they match, the client's identity is authenticated.

In summary, after this phase, the client and server go through an authenticated key exchange process so that they have a shared common secret pre_master secret. After that, the client and server have all the necessary pieces to derive the master secret.

Key Derivation

In this section, you learn how the SSL client and server use the data that is securely exchanged during the previous phases to create a master secret. The master secret is never exchanged, but rather created by the client and server individually. Several keys are then derived from the master secret for message encryption and integrity authentication. We will not get into the details of key derivation, but rather show the key conceptual steps so that you get a feel for this important phase. The SSL client and server use the following previously exchanged data to generate the master secret:

  • Pre-master secret

  • The client random and the server random

The key derivation algorithms of SSL v2, SSL v3, and TLS are different. Here you see the key generation of the SSL v3 and TLS protocols.

As defined in the SSL v3 protocol specification (SSL v3 draft 2), SSL v3 generates the master key using the following:

master_secret =    MD5(pre_master_secret + SHA('A' + pre_master_secret +      ClientHello.random + ServerHello.random)) +    MD5(pre_master_secret + SHA('BB' + pre_master_secret +      ClientHello.random + ServerHello.random)) +    MD5(pre_master_secret + SHA('CCC' + pre_master_secret +      ClientHello.random + ServerHello.random));master_secret =    MD5(pre_master_secret + SHA('A' + pre_master_secret +      ClientHello.random + ServerHello.random)) +    MD5(pre_master_secret + SHA('BB' + pre_master_secret +      ClientHello.random + ServerHello.random)) +    MD5(pre_master_secret + SHA('CCC' + pre_master_secret +      ClientHello.random + ServerHello.random));

The master secret is then used as an entropy source to derive sufficient keying material, which is eventually partitioned into the message encryption and authentication keys. Computing the following generates the key_block:

key_block =    MD5(master_secret + SHA('A' + master_secret +                ServerHello.random +                ClientHello.random)) +    MD5(master_secret + SHA('BB' + master_secret +                ServerHello.random +                ClientHello.random)) +    MD5(master_secret + SHA('CCC' + master_secret +                ServerHello.random +                ClientHello.random)) + [...];key_block =    MD5(master_secret + SHA('A' + master_secret +                ServerHello.random +                ClientHello.random)) +    MD5(master_secret + SHA('BB' + master_secret +                ServerHello.random +                ClientHello.random)) +    MD5(master_secret + SHA('CCC' + master_secret +                ServerHello.random +                ClientHello.random)) + [...];

From the key_block, the following keys are generated:

  • Client write key: The client uses this key to encrypt the data, and the server uses this key to decrypt client messages.

  • Server write key: The server uses this key to encrypt the data, and the client uses this key to decrypt server messages.

  • Client write MAC secret: The client uses this key to generate the MAC that is used for data integrity protection. The server uses this key to authenticate client messages.

  • Server write MAC secret: The server uses this key to generate the MAC that is used for data integrity protection. The client uses this key to authenticate server messages.

TLS uses a master key derivation that is similar to SSL v3. The master key is calculated as follows:

master_secret = PRF(pre_master_secret, "master secret",              ClientHello.random + ServerHello.random)[0..47];master_secret = PRF(pre_master_secret, "master secret",              ClientHello.random + ServerHello.random)[0..47];

Compared to SSL v3, a PRF function replaces the MD5 hashing function. The PRF function is defined as follows:

PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR P_SHA-1(S2, label + seed)PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR P_SHA-1(S2, label + seed)

where P_hash is mainly an HMAC function using MD5 or SHA-1, and S1 and S2 are the first and second halves of the input secret.

Using both MD5 and SHA-1 in TLS makes it a bit more secure than SSL v3. This is one of the reasons why TLS is FIPS (Federal Information Processing Standard) certified, whereas SSL v3 is not. More information about FIPS can be found at http://en.wikipedia.org/wiki/Federal_Information_Processing_Standard.

The corresponding key_block for TLS is generated by computing the following:

key_block = PRF(SecurityParameters.master_secret,          "key expansion",          SecurityParameters.server_random +          SecurityParameters.client_random);key_block = PRF(SecurityParameters.master_secret,          "key expansion",          SecurityParameters.server_random +          SecurityParameters.client_random);

Finishing Handshake

After the key derivation, the SSL VPN client and server are ready to finish the handshake and send the application data using the established secure connection. To signal readiness, the client and the server send the ChangeCipherSpec message to signal the other side that it is ready to use the negotiated security algorithms and keys. The ChangeCipherSpec message is then followed by the Finished message, which is protected by the newly negotiated security algorithms, keys, and secret.

The Finished message is basically a hash of the entire handshake message and Master Secret. The validation of the Finished message proves the success of the authentication and key exchange process. The following shows the structure of the Finished message.

For SSL v3:

struct {     opaque md5_hash[16];     opaque sha_hash[20];   } Finished;   md5_hash    MD5(master_secret + pad2 +            MD5(handshake_messages + Sender +              master_secret + pad1));   sha_hash    SHA(master_secret + pad2 +             SHA(handshake_messages + Sender +               master_secret + pad1));   handshake_messages  All of the data from all handshake messages              up to but not including this message. This              is only data visible at the handshake layer              and does not include record layer headers.struct {     opaque md5_hash[16];     opaque sha_hash[20];   } Finished;   md5_hash    MD5(master_secret + pad2 +            MD5(handshake_messages + Sender +              master_secret + pad1));   sha_hash    SHA(master_secret + pad2 +             SHA(handshake_messages + Sender +               master_secret + pad1));   handshake_messages  All of the data from all handshake messages              up to but not including this message. This              is only data visible at the handshake layer              and does not include record layer headers.

For TLS v1:

struct {  opaque verify_data[12];} Finished;verify_data  PRF(master_secret, finished_label, MD5(handshake_messages) +  SHA-1(handshake_messages)) [0..11];finished_label  For Finished messages sent by the client, the string "client  finished". For Finished messages sent by the server, the  string "server finished".handshake_messages  All of the data from all handshake messages up to but not  including this message. This is only data visible at the  handshake layer and does not include record layer headers.struct {  opaque verify_data[12];} Finished;verify_data  PRF(master_secret, finished_label, MD5(handshake_messages) +  SHA-1(handshake_messages)) [0..11];finished_label  For Finished messages sent by the client, the string "client  finished". For Finished messages sent by the server, the  string "server finished".handshake_messages  All of the data from all handshake messages up to but not  including this message. This is only data visible at the  handshake layer and does not include record layer headers.

After this phase, the SSL client and server start to transfer application data.

Application Data

After the handshake phase, the application can begin to communicate under the protection of the newly established secure SSL connection. The record protocol is responsible for fragmenting, compressing, hashing, and encrypting all the application data at the sending side, as well as decrypting, verifying, decompressing, and reassembling messages at the receiving end.

Figure 2-9 shows the SSL record layer operation.

Figure 2-9

SSL/TLS Record Protocol Operation

Case Study: SSL Connection Setup

The section examines the setup of an SSL connection as a case study of the workings and implementations of the concepts we have discussed so far. The section examines the communications from both the SSL session level and lower TCP/IP packet level using tools such as ssldump and ethereal.

The SSL connection used in this case study is fairly simple. A user at IP address 10.1.1.200 browses to a website at IP address 66.94.230.34 using HTTPS, views the page, and then closes the connection. First, look at Example 2-1. This shows the client-server exchanges that are captured by using ssldump, which is installed on the user's PC. The ssldump is a tool written by Eric Rescorla to analyze SSL exchanges.

Example 2-1  SSL Session Dump

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