TLS Inspection detects and prevents advanced threats in your network over encrypted TLS channels. This topic includes concepts associated with TLS Inspection features.

TLS Protocol

This topic describes how TLS protocol handshake works to establish an encrypted channel between the client and the server. The following TLS protocol illustration provides the various steps involved to form an encrypted channel.
Figure 1. TLS Protocol
TLS three-way handshake
To summarize the TLS protocol:
  • TLS initiates a TLS session over an established TCP session between the client and the server (aka a three-way handshake).
  • The client sends a Client Hello that includes the supported TLS version and cipher and the Server Name Indication (SNI) extension. SNI in the TLS Client Hello is what TLS Inspection uses to classify the traffic using the context profile to use the internal, external, or bypass decryption profiles.
  • The server responds with the server certificate for authentication and identification and a Server Hello with the version and cipher proposed by the client.
  • Once the client validates the certificate and verifies the final version and cipher, it generates a symmetric session key and sends it to the server.
  • To initiate the secure TLS tunnel which exchanges application data over the encrypted TLS channel, the server validates the session key and sends the finished message.

By default the TLS protocol only proves the identity of the server to the client using X.509 certificate and the authentication of the client to the server is left to the application layer.

TLS Decryption Types

The TLS Inspection feature allows users to define policies to decrypt or to bypass the decryption, the TLS Inspection feature allows two types of decryption:
  • Internal TLS Decryption - for traffic going to an Enterprise internal service where you own the service, certificate, and the private key. This is also called TLS reverse-proxy or inbound decryption.
  • External TLS Decryption - for traffic going to an external service (Internet) where the Enterprise does not own the service, its certificate, and the private key. This is also called TLS forward proxy or outbound decryption.
The following diagram depicts how the traffic is handled by the TLS internal and external decryption types.
Figure 2. NSX TLS Decryption Types
NSX Gateway firewall TLS decryption of internal and external types
The following diagram and table explain how NSX TLS External decryption works with NSX.
Figure 3. How External Decryption Works
Workflow of external decryption for TLS Inspection
Callout Workflow
1 TLS client hello SNI matches the TLS Inspection policy context profile.
2 NSX intercepts the TLS session from the client and initiates a new session to the intended server.
3 NSX enforces TLS version and cipher (which is configurable). .
4 The server responds to the client with a TLS certificate
5 NSX validates the server certificate using the trusted CA bundle and generates a proxy CA certificate dynamically and presents that to the client.

The following diagram and table explain how NSX TLS Internal decryption works with NSX.

Figure 4. How Internal Decryption Works
Worfkflow of external decryption for TLS Inspection
Callout Workflow
1 TLS client hello SNI matches the TLS Inspection policy context profile configured for internal domain.
2 NSX intercepts the TLS session from the client and initiates a new session to intended server.
3 NSX enforces TLS version/cipher (configurable).
4 Server responds with certificate as part of TLS handshake (validation optional).
5 NSX presents the certificate of the server, which was uploaded as part of the configuration, to the client.