Chapter 2: SSL VPN Technology

Cisco Press

1 2 3 4 5 6 7 Page 3
Page 3 of 7

The following sections give a brief overview of a number of protocols: OSI Layer Placement and TCP/IP Protocol Support, SSL Record Protocol and Handshake Protocols, SSL Connection Setup, and 42Application Data. The sections end with a case study to demonstrate how SSL Connection Setup works.

OSI Layer Placement and TCP/IP Protocol Support

SSL is a platform-independent and application-independent protocol that is used to secure TCP-based applications. It sits on top of the TCP layer, below the application layer, and acts like sockets connected by TCP connections. Figure 2-6 shows the SSL placement in the protocol stack.

Figure 2-6

SSL and TCP/IP

SSL assumes reliable underlying packet delivery; thus, it always runs only on top of TCP, not over UDP or directly over IP. Although SSL should work with any static client-server TCP application in an ideal situation, in reality, it is not as easy as simply replacing the TCP socket calls with SSL calls. For the most popular applications defined in the TCP/IP suite, such as HTTP and Simple Mail Transfer Protocol (SMTP), standards have been defined for all the technical details to be used for SSL to secure the communications. The following are two well-known examples:

  • HTTP over SSL: Securing the web was the main initial drive for designing SSL, and HTTP is the first application-layer protocol secured by SSL.

  • When Netscape first implemented HTTP over SSL in its Navigator, it used https:// for the pages that are fetched using HTTP over SSL to differentiate them from the standard pages that are fetched using HTTP with http://. HTTP over SSL then became known as HTTPS, which stands for HTTP over SSL. HTTPS later was standardized in RFC 2818. HTTPS operates on TCP port 443, while HTTP operates on TCP port 80 by default.

    People have much the same user experience using HTTPS and HTTP. After the users enter https://URL in the browser, the browser, as a client, makes a connection to the server and negotiates an SSL connection. After the SSL connection is established, the HTTP data is transmitted over the SSL tunnel.

  • Email over SSL: Similar to HTTP over SSL, e-mail protocols such as SMTP, Post Office Protocol 3 (POP3), and Internet Message Access Protocol (IMAP) can be supported by SSL.

  • The standard for SMTP over TLS was documented in RFC 2487.

    The standard for POP3 and IMAP over TLS was documented in RFC 2595.

Later, we discuss how to use an SSL VPN to secure Microsoft Exchange Protocol.

SSL Record Protocol and Handshake Protocols

This section describes the SSL protocol operation, including SSL connection negotiation, key derivation, and secure data transfer. The section explains how the various cryptographic elements described earlier are used in SSL to build a secure communication.

An SSL connection is established in two main phases. The handshake phase (phase 1) negotiates cryptographic algorithms, authenticates the server, and establishes keys for data encryption and MAC. The secure data transfer phase (phase 2) is under the protection of an established SSL connection. This chapter describes each phase in detail, but we first look at the structure of the SSL protocol.

SSL is a layered protocol. At the lowest layer is the SSL record protocol. The record protocol consists of several message types or protocols carrying out different tasks. Figure 2-7 shows the SSL protocol structure.

Figure 2-7

SSL/TLS Protocol Structure

The following list describes the primary functions of each protocol defined in SSL/TLS:

  • Record protocol is mainly an encapsulation protocol. It transmits various higher-level protocols and application data. The record protocol takes messages to be transmitted from upper-client protocols; performs the necessary tasks such as fragmentation, compression, applying MAC, and encryption; and then transmits the final data. It also performs the reverse actions—decryption, verification, decompression, and reassembly—to the receiving data. The record protocol consists of four upper-layer client protocols: Handshake Protocol, Alerts Protocol, Change Cipher Spec Protocol, and Application Data Protocol.

  • Handshake protocols are responsible for establishing and resuming SSL sessions. Three subprotocols exist:

    Handshake Protocol negotiates the security attributes of an SSL session.

    Alerts Protocol is a housekeeping protocol that is used to convey alert messages between the SSL peers. The alert messages contain errors, exception conditions such as a bad MAC or decryption failure, or notification such as a closure of the session.

    Change Cipher Spec Protocol is used to signal transitions in cipher strategies in the subsequent records.

  • Application Data Protocol handles the transmission of upper-layer application data.

Note that the TLS record protocol was designed as a framework, and new client protocols can be easily added in the future. The client protocols previously described are those that are used in SSL connections.

SSL Connection Setup

This section looks at the messages and operations necessary to establish an SSL connection. Using a simple-mode SSL negotiation as an example should help you understand how the different pieces discussed so far (cryptographic algorithms and SSL protocols) work together to bring up an SSL connection.

Because you are mainly an SSL VPN user rather than an implementer, the focus is on explaining the big picture, not the implementation details.

Handshake protocols are used for the SSL client and server to establish the connection. The main tasks of this process are as follows:

  • Negotiate security capabilities: This handles protocol version and cipher suites.

  • Authentication: The client authenticates the server. Optionally, the server can also authenticate the clients.

  • Key exchange: Two parties exchange keys or information that is needed to generate the master keys.

  • Key derivation: The two parties derive the master secret that is later used to generate keys used for bulk data encryption and MAC.

Figure 2-8 shows the flow and messages of a typical SSL connection setup. Each block has a few SSL handshake messages with the format of <protocol:message_type> and each represents one or more (if fragmentation exists) TCP frame sent by the client or the server.

To help you understand the steps that take place during a handshake, the sections that follow break messages down into a few logical phases, each of which accomplishes one of the main tasks described in the preceding bulleted list.

Figure 2-8

TLS Handshake

Hello Phase

During this phase, the client and the server start the logical connection and negotiate the basic security attributes of the SSL session, such as SSL protocol versions and cipher suites. The client initiates the connection, first by sending a ClientHello message that is defined as follows:

struct {  ProtocolVersion client_version;  Random random;  SessionID session_id;  CipherSuite cipher_suites<2..2^16-1>;  CompressionMethod compression_methods<1..2^8-1>;} ClientHello; struct {   ProtocolVersion client_version;   Random random;   SessionID session_id;   CipherSuite cipher_suites<2..2^16-1>;   CompressionMethod compression_methods<1..2^8-1>; } ClientHello;

From the preceding definition, you can see that the ClientHello message contains the following:

  • Protocol version: The protocol version field defines the highest SSL version that the client supports. It is defined in the format of <major version.minor version>. For example, for SSL v3, the major version is 3 and the minor version is 0. So the protocol version is 3.0. For TLS, the protocol version is 3.1.

  • Client random: This is a client-generated random structure that has both temporal information and randomly generated data. It contains the client's date and time plus a 28-byte pseudorandom number. This client random is later used to calculate the master secret and to prevent replay attacks.

  • Session ID (optional): A session ID identifies an active or resumable session state. An empty session ID indicates that the client wants to establish a new SSL connection or session, while a nonzero session ID indicates that the client wants to resume a previous session.

  • Client CipherSuite: This is the list of cipher suites that are supported by the client. The cipher suite defines a set of cryptographic algorithms that are used throughout the SSL connection, such as authentication and key exchange methods, data encryption algorithms, and message digest algorithms. For example, TLS_RSA_WITH_RC4_128_SHA means that it supports TLS and uses RSA for authentication and key exchange, RC4 with a 128-bit key for data encryption algorithms, and SHA-1 for message digest algorithms used in MAC.

  • Compression method: Defines the compression methods supported by the client.

Upon receiving the ClientHello message, the sever replies with the ServerHello as part of the reply message. The ServerHello has the same structure as the ClientHello:

struct {  ProtocolVersion server_version;  Random random;  SessionID session_id;  CipherSuite cipher_suite;  CompressionMethod compression_method;} ServerHello;struct {  ProtocolVersion server_version;  Random random;  SessionID session_id;  CipherSuite cipher_suite;  CompressionMethod compression_method;} ServerHello;

The server sends back the highest protocol version that is supported by the client and the server. The client and server will use this version throughout the connection. The server also generates its own server random that will later be used to generate the master secret. CipherSuite is the single cipher suite selected by the server out of the cipher suites proposed by the client. For the session ID, the following two scenarios exist:

  • New session ID: If the client sends an empty session ID to initiate a new session, the server generates a new session ID. Or, if the client sends a nonzero session ID asking to resume a session, but the server cannot or will not resume the session, the server also generates a new session ID.

  • Resumed session ID: The server uses the same session ID that is sent by the client who asks to resume a previous session.

Finally, the server also replies by using the selected compression method in the ServerHello.

In summary, after the hello phase, the client and server have initiated a logical connection, and negotiated security attributes such as protocol version, cipher suites, compression methods, and session ID. They have also generated nonce (client random and server random) that will be used later for master key generation.

Authentication and Key Exchange

After the hello exchange, the client and server use the negotiated security attributes to move on to perform authentication and key exchange. In this phase, the client and server need to come up with an authenticated shared secret, called a pre_master secret, which is later converted into a master secret.

SSL v3 and TLS support several authentication and key exchange methods. The exact payloads in SSL exchange messages 2 and 3 shown in Figure 2-9, depending on the methods used during the exchange. The following are the main key exchange methods supported by SSL v3 and TLS:

  • RSA: This is the most common authentication and key exchange method. In this mode, the client generates a random secret as the pre_master secret and sends the encrypted pre_master secret to the server in the ClientKeyExchange message. The pre_master secret is encrypted by the server's RSA public key that is authenticated by the server's certificate, which is sent by the server in the Certificate message.

  • Ephemeral RSA, also known as RSA-export in cipher spec, is used to support the scenario in which an exported client with 512-bit RSA keys (because of crypto export regulations) needs to communicate with a domestic server with strong 1024-bit or higher RSA keys. In this case, the server generates a temporary 512-bit RSA key and sends it to the client through a ServerKeyExchange message that is signed by the server's strong key. The client then uses this temporary 512-bit key to encrypt the pre_master secret.

  • Diffie-Hellman: The client and server perform a DH exchange and use the calculated DH common secret as the pre_master secret. Three types of Diffie-Hellman key exchange methods exist: fixed Diffie-Hellman, ephemeral Diffie-Hellman, and anonymous Diffie-Hellman. The anonymous DH does not have authentication. Hence, it is vulnerable to man-in-the-middle attacks, as mentioned earlier in the discussion of the DH algorithm.

The next section features the most commonly used RSA key exchange method as an example to explain exchange messages during this phase.

After the ServerHello message, the server sends the Certificate message and the ServerHelloDone message. The Certificate message contains the public key certificate of the server. The ServerHelloDone message is a simple message that indicates that the server has sent all the messages it needs to send in this phase.

When an RSA key exchange is used, the client needs to generate the pre_master secret and send it using a ClientKeyExchange message. The pre_master secret and the ClientKeyExchange message are defined as follows:

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