Break and Inspect: When the Network Becomes a TLS Endpoint

A break-and-inspect middlebox solves the TLS 1.3 visibility problem by changing where the protected connection ends. This chapter explains the two TLS sessions created by that change, how cleartext reaches passive or inline analytics, and what an enterprise gains and risks by placing a trusted component in the traffic path. The useful judgment is not whether a middlebox can decrypt traffic—it can in the demonstrated real-time design—but whether the added trust boundary and failure surface are justified by the need for immediate inspection or enforcement.

One device, two TLS relationships

In passive inspection, the client and server remain the endpoints of one TLS relationship while a tap copies the packets. A break-and-inspect design takes a different route. The middlebox terminates the TLS session from the client, decrypts the payload, and then initiates a new TLS session with the intended server. It is therefore an endpoint on the client-facing side and a client on the server-facing side.

The distinction is easy to miss when the application appears to have one continuous conversation. The traffic may represent one user request and one server response, but the cryptography is divided into two sessions. The client negotiates one session with the middlebox. The middlebox negotiates another with the server. The two sessions have different session keys. A key that opens the client-to-middlebox side does not automatically open the middlebox-to-server side, and a post-facto record must identify which side’s traffic it is trying to analyze.

The middlebox needs the ability to act as the intended server toward the client. In the NIST reference build, the appropriate server certificates and private keys are loaded into the middlebox. The device uses them while negotiating the client-facing connection, then uses the enterprise’s public-key infrastructure and its own session establishment to create the server-facing connection. This is a substantial trust decision. The middlebox is not merely receiving a copy of a secret from an otherwise unchanged endpoint; it is being entrusted with credentials and a position from which it can observe the connection as it happens.

After the first session is decrypted, the middlebox can branch the cleartext in two ways. A passive analytic tool consumes a copy and produces alerts or measurements without changing the payload. An inline tool receives the cleartext, processes it, and returns it to the middlebox; the tool may modify the traffic before the middlebox re-encrypts and forwards it. The distinction matters when an operator is diagnosing a failure. A passive alert indicates what the tool observed. An inline control may itself affect what the server or client receives.