SSL Sessions

Secure Sockets Layer (SSL) is a protocol that allows the transmission of secure data between a server and client. Transport Layer Security (TLS) is a cryptographic protocol that adds security to TCP/IP communication.

Inline SSL decryption supports SSL version 3.0 and TLS versions 1.0, 1.1, 1.2, and 1.3.

TLS and SSL are used in communications such as Web browsing, email, instant messaging, and voice over IP (VoIP). TLS and SSL encrypt these communications.

The client initiates the SSL session. The GigaVUE node intercepts the connection and negotiates an SSL session with the client.

The GigaVUE node monitors all TCP connections, then intercepts the SSL session. Non-TCP traffic is passed transparently without any changes.

All the incoming SSL traffic terminates on the GigaVUE node. The SSL connections are decrypted in inbound or outbound deployments, passed to the inline tools, and eventually to the server.

The session to the client is terminated on the GigaVUE node, but information about the session, such as the initiator’s IP address is maintained, so that the GigaVUE node can “reconnect” the client and server.

The GigaVUE node performs SSL decryption and feeds tools, either inline or out-of-band.

The session to the server is from the GigaVUE node to the server. The GigaVUE node negotiates a new SSL session with the server.

SSL encryption secures traffic between a client and a server, such as a Web server. 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 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.

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

Figure 91 Basic SSL Handshake

The SSL handshake steps in Figure 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.

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

Figure 92 Man-in-the-Middle SSL Handshake

Figure 93 Inbound Deployment of Inline SSL Decryption

Figure 3 shows an inline 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 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 SSL handshake with the server parameters from the SSL client’s Hello request.
4. Gigamon establishes the SSL handshake with the client using the server’s certificate and key, and using the appropriate parameters.

Figure 94 Outbound Deployment of Inline SSL Decryption

Figure 4 shows an inline 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 not have access to the private keys.

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

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

Once a session has been established, the keys are saved so a session can be resumed efficiently later. The resumed 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 SSL Decryption solution looks for the CLIENT HELLO packet and, when found, it switches to 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 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 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 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.