TLS/SSL Sessions

Secure Sockets Layer (SSL) is a protocol that enables secure data transfer between a client and server. Transport Layer Security (TLS) builds on SSL and adds stronger cryptographic protection for TCP/IP communication.

A TLS/SSL session begins when the client initiates a connection. The GigaVUE node intercepts this request and negotiates a TLS/SSL session with the client. The node monitors all TCP connections and intercepts TLS/SSL sessions, while non-TCP traffic passes through unchanged.

All incoming TLS/SSL traffic terminates on the GigaVUE node. The node decrypts traffic for inbound or outbound deployments, forwards it to inline tools, and then passes it to the server.

The GigaVUE node maintains session details such as the client’s IP address, allowing it to “reconnect” the client and server after decryption. The node also negotiates a new TLS/SSL session with the server. TLS/SSL traffic can be sent to tools inline or out-of-band.

TLS/SSL Handshake

TLS/SSL encryption secures traffic between client and server. Decryption uses keys to decode this traffic. TLS/SSL protocols define a series of handshake messages that set up and tear down a secure connection.

During the handshake, the client and server use Public Key Infrastructure (PKI) to exchange encryption keys for data transfer.

TLS/SSL Handshake Steps:

1. The client sends a Client Hello message with its supported TLS/SSL version, cipher suites, and a random number.

2. The server replies with a Server Hello message. It selects a cipher suite, sends its supported version, a random number, and its digital certificate.

3. The client verifies the server’s certificate.

4. Using the random numbers, the client creates a pre_master_secret, encrypts it with the server’s public key, and sends it.

5. The server verifies the client certificate if requested.

6. The client sends a Client Finished message, encrypted with the shared secret key, confirming its part of the handshake.

7. The server responds with a Server Finished message, also encrypted, confirming its part of the handshake.

8. The session is now established, and both sides use the shared secret key for encrypted communication.

TCP Transition States during TLS/SSL Session

The TCP handshake moves through different states during a TLS/SSL session:

■

(Na:SYN RCV:Nb:SYN_SENT:INIT:INIT): Client SYN received; TCP handshake starts on the server side. If the server is busy or unreachable, the session resets.

■

(Nb:SYN_RCV: EST:INIT:INIT): TCP handshake is complete on the server side.

■

(Na:EST:Nb:EST:Na:INIT:Nb:INIT): TCP handshake complete between client and server; session may be decrypted depending on policy.

■

(Na:EST:Nb:EST:Ta:SYN_SENT:Tb:INIT): Decryption decision made; tool-side TCP handshake begins.

■

(EST:EST:Ta:SYN_SENT:Tb:SYN_RCV): Tool-side TCP handshake continues.

■

(EST:EST:EST:EST): TCP handshake successfully established

TLS/SSL Session Resumption

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.

TLS/SSL Session Search

You can search for an existing TLS/SSL session by hostname. The system matches the input against the Server Name Indication (SNI) or the certificate subject name of current sessions.

StartTLS and HTTP CONNECT

When the system detects a CLIENT HELLO packet, it switches to TLS/SSL mode.

■

StartTLS: Allows protocols like SMTP, IMAP, and POP3 to begin in plaintext, then upgrade to TLS/SSL on the same port. Up to 20 ports can be monitored for StartTLS traffic.

■

HTTP CONNECT: Used by explicit proxies to establish an HTTP session, then upgrade to TLS. Detection is automatic.

Both methods add security by upgrading existing plaintext protocols.

Behavior with StartTLS

■

If StartTLS is used, Inline TLS/SSL decryption works if the decision to decrypt is made at the certificate phase.

■

If the CLIENT HELLO packet does not have SNI, policy rules are applied during the certificate phase.

Explicit proxy traffic also applies policy rules during the certificate phase.

Note:  StartTLS must be enabled for decryption of sessions that use explicit proxy.