TLS Traffic Visibility

TLS 1.3 has created a problem for enterprise data centers known as the TLS 1.3 traffic visibility problem, or the PFS session visibility problem (where PFS is short for “perfect forward secrecy”). The latest version of the TLS protocol has discontinued the use of a static RSA key for key exchange, leaving Ephemeral DH (DHE) and Ephemeral ECDH (ECDHE) as the only key exchange primitives based on asymmetric cryptography. These primitives provide forward secrecy, but make it impossible to inspect TLS traffic in the intranet by provisioning a middlebox with a static RSA key, as is done for earlier versions of protocol. Since traffic inspection is necessary for essential tasks such as troubleshooting, attack detection and compliance audits, enterprises cannot migrate to TLS 1.3 without a solution to this problem.

The following series of blog posts discusses the problem and proposes three variants of a Pomcor visibility solution based on the establishment of an (EC)DHE visibility shared secret (VSS) between the TLS server and a passive middlebox. It also provides a survey of traffic visibility solutions for both TLS 1.2 and TLS 1.3 and a discussion of the related Multiple Protection State problem in the last post.

  1. Reconciling Forward Secrecy with Network Traffic Visibility in Enterprise Deployments of TLS 1.3. This post proposes the original Pomcor visibility solution, applicable to the (EC)DHE key exchange mode of TLS 1.3, where the TLS server and the middlebox use ephemeral key pairs to establish the VSS and use the bits of the VSS to independently derive the server’s TLS private key, then the TLS shared secret.
  2. Protocol-Level Details of the TLS 1.3 Visibility Solution. This post provides full details of the original Pomcor visibility solution, and shows an interleaving of solution steps with TLS messages.
  3. Extending the TLS 1.3 Visibility Solution to Include PSK and 0-RTT. This post extends the Pomcor visibility solution to all three key exchange modes of TLS 1.3, and introduces a Secret Transmission (ST) variant of the solution where the bits of the VSS are used to derive an AEAD key and AEAD nonces for protecting messages transmitting the TLS 1.3 traffic secrets from the TLS server to the visibility middlebox. It refers to the original variant as the Secret Derivation (SD) variant.
  4. A Two-Version Visibility Solution for TLS 1.2 and TLS 1.3 based on a Handshake-Agnostic Middlebox. This post introduces the two-version (2V) variant of the Pomcor visibility solution, which is applicable to both TLS 1.2 and TLS 1.3. As in the ST variant, the bits of the VSS are used to derive an AEAD key and AEAD nonces, but the AEAD key and nonces are used to encrypt protection states that the server sends to the middlebox, instead of traffic secrets. The post also shows how the VSS can be precomputed in all three variants of the Pomcor visibility solution to avoid increasing the latency of the TLS handshake.
  5. A Survey of Existing and Proposed TLS Visibility Solutions. This post provides a survey of TLS visibility solutions for TLS 1.2 and TLS 1.3. It also describes the Multiple Protection State problem, which prevents some PFS visibility solutions that work in TLS 1.2 from working in TLS 1.3.

The following post discusses a response to the last post of the series received from the Nubeva:

The following post shows how the “early data” or “0-RTT” feature of TLS 1.3 can be used by an attacker as an encrypted steganographic channel, and how two of our visibility solutions can mitigate this risk:

Background materials in chronological order: