Exported Session Keys: Precision Without Reusing Server Keys
A TLS 1.3 server can support passive visibility without sharing a reusable server key pair by exporting the symmetric secret for each negotiated connection. This chapter follows that per-session key from capture to real-time decryption and later retrieval, using the client-random-id to connect key material with a copied flow. The design’s appeal is precise scope: one exported secret corresponds to one connection. Its cost is equally precise: every connection can create another sensitive record that must be transported, matched, protected, retained, and deleted.
The connection becomes the unit of access
A session key is the symmetric key material used to protect one client-server connection after the TLS session has been negotiated. It is different from the server’s long-term identity key and different from the bounded-lifetime Diffie-Hellman pair used across an epoch. The exported-session-key design gives an approved decryptor the session secret itself, rather than asking the decryptor to derive many session secrets from a server key that covers a period of time.
The association between a secret and a connection is essential. A packet capture contains many flows, and a busy server may negotiate many sessions at once. The NIST design uses the TLS client-random-id as the flow-identification mechanism. The field is present in the TLS handshake and, in the guide’s description, is available in plaintext to identify the session. The identifier does not grant access by itself. It tells a decryptor or key-governance platform which registered session key belongs with the captured handshake and its traffic.
The real-time sequence begins when the TLS server negotiates a new session with a client. A key-capture and registration agent on the server observes the negotiated session key. It sends the key together with the client-random-id to the real-time decryptor. The same information is registered with the key-governance platform so that a later request can be answered. Meanwhile, a network tap copies the encrypted packets exchanged by the client and server and forwards them to the decryptor.
The decryptor now joins two streams of information. From the packet copy, it reads the client-random-id and identifies the corresponding flow. From the key-capture path, it receives the session key associated with that identifier. It uses the key to decrypt the copied traffic and forwards the resulting view to the real-time analytics platform. The original client-server connection remains intact; the visibility path consumes a copy rather than terminating the application’s TLS session.
The word “exported” can sound as if the server is handing over a general ability to decrypt its traffic. That is not the scope described here. The event that creates the access record is the negotiation of one session, and the item registered for that event is the symmetric key for that session. The client-random-id then acts as the join field between the server-side event and the network-side observation. Without that join, the key is only an orphaned secret and the packet copy is only an unreadable record.
This also explains why the capture agent is part of the security boundary, not just a convenience plug-in. It observes sensitive material at the point where the server creates it and sends that material to another component. A failure in the agent can leave the application’s TLS session healthy while depriving the monitoring plane of a real-time key. A compromise of the agent, its transport, or its receiving decryptor can expose the session secrets it handles.