TLS/SSL Sessions

TLS/SSL encryption secures traffic between a client and a server, such as a Web server. TLS/SSL decryption uses keys to decode the traffic between the client and server.

SSL and Transport Layer Security (TLS) protocols consist of a set of messages exchanged between a client and server to set up and tear down the TLS/SSL connection between them. To set up the connection, the client and server use the Public Key Infrastructure (PKI) to exchange the bulk encryption keys needed for data transfer.

1 shows the basic TLS/SSL handshake between a client and server to establish a session.

1

Basic RSA TLS/SSL Handshake

The TLS/SSL handshake steps in 1 are as follows:

1.

The SSL or TLS client sends a Client Hello message that contains information such as the SSL or TLS version and the list of cipher suites supported by the client. The message also contains a client random number.

2.

The SSL or TLS server responds with a Server Hello message that contains the SSL or TLS version it supports and the cipher suite chosen by the server from the list provided by the client, and a server random number. The server also sends its digital certificate.

3.

The SSL or TLS client verifies the server's digital certificate.

4.

Using the random numbers from the Hello messages, the SSL or TLS client computes the pre_master_secret that enables both the client and the server to compute the secret key to be used for encrypting subsequent message data. The pre_master_secret is encrypted with the server's public key and sent.

5.

The SSL or TLS server verifies the client's certificate.

6.

The SSL or TLS client sends the server a Client Finished message containing a digest (MAC) of the messages in the handshake, which is encrypted with the secret key, indicating that the client part of the handshake is complete.

7.

The SSL or TLS server sends the client a Server Finished message containing a digest (MAC) of the messages in the handshake, which is encrypted with the secret key, indicating that the server part of the handshake is complete.

8.

For the duration of the SSL or TLS session, the server and client can now exchange messages that are symmetrically encrypted with the shared secret key.

2 shows the TLS/SSL handshake when a Man-in-the-Middle sits between the client and server.

2

Man-in-the-Middle TLS/SSL Handshake

3

Inbound Deployment of Inline TLS/SSL Decryption

3 shows an inline TLS/SSL decryption inbound deployment. The client is on the Internet. The server and the GigaVUE node are located within the same enterprise network, with the GigaVUE node deployed on the server side. The GigaVUE node needs access to the private keys of the server.

The TLS/SSL session is created as follows:

1.

Client traffic, such as from the Internet, arrives on an inline-network port on the GigaVUE node and establishes a TCP connection.

2.

The GigaVUE node initiates a TCP connection to the server.

3.

Gigamon establishes the TLS/SSL handshake with the server parameters from the TLS/SSL client’s Hello request.

4.

Gigamon establishes the TLS/SSL handshake with the client using the server’s certificate and key, and using the appropriate parameters.

4

Outbound Deployment of Inline TLS/SSL Decryption

4 shows an inline TLS/SSL decryption outbound deployment. The client is in your network, and it connects to a server outside your network on the Internet. Traffic is destined to servers where you do not have access to the private keys.

The TLS/SSL session is created as follows:

1.

Client traffic, such as from an employee on the enterprise’s Intranet is destined to a server on the Internet. The traffic arrives on a network port on the GigaVUE node.

2.

Gigamon initiates a new connection to the server as the client.

3.

The server responds with its server certificate and presents it to Gigamon.

4.

Gigamon spoofs the server certificate and presents it to the client, but now the certificate is signed by Gigamon.

5.

The end client verifies that the certificate is valid as it belongs to the server and has been signed by Gigamon, which has been listed as one of the valid CAs.

6.

Gigamon now maintains two TCP connections, one with the client and one with the server.

TCP Transition States during TLS/SSL Session

The TCP transition starts with INIT state during a session.

The following are the different states and its what it indicates:

■

(Na:SYN RCV:Nb:SYN_SENT:INIT:INIT) - This status indicates that the client side has received the SYN and due to that the TCP session handshake has started from the server side of GigaVUE device. If the TCP handshake on the server is not successful, that is if the server is unreachable/busy, this connection is reset.

■

(Nb:SYN_RCV: EST:INIT:INIT)- This status indicates that TCP handshake has been established at the server side of GigaVUE device.

■

(Na:EST:Nb:EST:Na:INIT:Nb:INIT)- This status indicates that the TCP handshake has been established between the Client and Server side. The session will either be decrypted or not decrypted based on the policy.

■

(Na:EST:Nb:EST:Ta:SYN_SENT:Tb:INIT) - This status indicate that either decryption or no decryption decision has been made and now the tool side TCP handshake would be initiated.

■

(EST:EST:Ta:SYN_SENT:Tb:SYN_RCV) - This status indicates that either decryption or no decryption decision has been made, so the tool side TCP session is initiated, with SYN received on the tool server side.

■

(EST:EST:EST:EST) - This indicates that a successful TCP handshake has been established.

TLS/SSL sessions can be resumed to improve performance. TLS/SSL session resumption speeds up the TLS/SSL handshake.

Once a session has been established, the keys are saved so a session can be resumed efficiently later. The resumed TLS/SSL handshake has fewer steps.

Session identifier-based resumption is supported. The GigaVUE node maintains the session identifier data in the cache. Session ticket-based resumption is not supported.

By default, resumption is enabled.

Starting in software version 5.2, you can search an existing session based on a hostname. The input is matched against the Server Name Indication (SNI) or the certificate subject name of the current sessions.

The Inline TLS/SSL Decryption solution looks for the CLIENT HELLO packet and, when found, it switches to TLS/SSL mode. The StartTLS command is initiated from the client or the server when switching from non-SSL to SSL mode.

Using the StartTLS mechanism, protocols such as SMTP, IMAP, and POP3 can be decrypted. These protocols start in plaintext mode and then upgrade to TLS/SSL mode on the existing port instead of using another port.

HTTP CONNECT provides a mechanism for explicit proxies where an HTTP session is established between a client and a server, and then upgraded to TLS. HTTP CONNECT is automatically detected.

Both StartTLS and HTTP CONNECT are upgrade related protocols that adds security to an existing insecure protocol and included in iSSL StartTLS command.

When enabling StartTLS, the specific ports to monitor StartTLS traffic must be specified. Up to 20 ports can be monitored.

For connections that use StartTLS to upgrade from non-TLS mode to secure mode, the inline TLS/SSL decryption solution decrypts correctly if the decision to decrypt or not is made in the certificate phase.

If the CLIENT HELLO packet does not have SNI information, the inline TLS/SSL decryption solution will apply policy rules in certificate phase of the policy evaluation.

For explicit proxy connections policy, rules are applied in certificate phase of policy evaluation. For information on the certificate phase of policy evaluation, refer to Policy Evaluation.

Note:  You need to enable StartTLS for decryption sessions established through explicit proxy.