Summary

  • RFC 9850 standardizes SSLKEYLOGFILE as a three-field record: a secret label, a ClientHello random and a secret. With captured traffic and enough connection context, those values can remove TLS protection; the file alone contains no timestamp, endpoint identity, authorization, provenance or custody record.
  • The capability is destructive as well as diagnostic. Logged material can expose stored traffic, permit injection into an active connection, undermine exporter-based application security, defeat forward secrecy and, for a TLS 1.2 master secret, enable still broader impersonation.
  • The RFC confines the mechanism to systems where TLS protects test data and says it MUST NOT be used in production. Successful decryption proves compatibility between key material and records, not who communicated, why logging was enabled or whether collection was legitimate.

When readable plaintext becomes too large a conclusion

An analyst loads a capture into a diagnostic tool, adds a key-log file and watches encrypted records turn into readable application data. The transformation is executable and repeatable. It feels stronger than an ordinary log line because the bytes do something.

That fact deserves a precise sentence: this secret material, these captured records and this reconstruction procedure were mutually usable. It does not deserve the larger sentence that often follows: therefore the file proves the session, its participants and the history asserted in the incident report.

Those propositions need different evidence. The capture needs an acquisition time, interface, filter and hash. The file needs a source process, permissions, collection path and custody record. The endpoint needs an asset identity. The user needs a separately supported attribution. The act of enabling logging needs authority. The analyst's output needs a tool version and reproducible procedure. TLS key material can make content visible; it cannot silently manufacture those missing receipts.

RFC 9850 is valuable partly because its technical claim is smaller than the operational mythology that can grow around it.

A standard for an existing diagnostic practice

Published in July 2026 as an Informational IETF RFC, The SSLKEYLOGFILE Format for TLS is authored by Martin Thomson, Yaroslav Rosomakho and Hannes Tschofenig. Its acknowledgements resist the story of a lone inventor: the format originated in the Network Security Services project, changed as TLS evolved and was documented by the authors while being extended for Encrypted Client Hello.

In the IETF Datatracker record saved on 1 September, Thomson is described as a Mozilla engineer and 45 RFCs appear under his public identity. That record situates a long contribution to HTTP, QUIC, TLS-adjacent and other protocol work. It does not make Thomson the operator of a reader's browser, the approver of a forensic collection or the authority over every implementation that adopts the convention.

IANA now maintains a registry of SSLKEYLOGFILE labels. Registration supplies shared spelling and reference points so producers and tools can interoperate. The RFC explicitly warns that expert approval of a new label is not endorsement of that label. A registry can make an artifact legible without blessing the circumstances in which it is produced.

Three fields, and no hidden certificate

Each non-comment SSLKEYLOGFILE line has three space-separated values. The label states what kind of secret is being conveyed. The client_random is the 32-byte Random field from the ClientHello and can distinguish one connection from another within a file. The secret carries the named secret in hexadecimal.

That economy is why the format travels well between implementations and analysis tools. It is also the boundary of what the line can assert.

The following conclusion is an inference from the defined fields, not a quotation from the RFC: the format contains no required timestamp, hostname, IP address, port, certificate chain, process identifier, user identity, authorization decision, file-access history, packet-capture reference or chain of custody. A ClientHello random is a correlation value, not a person's name and not a statement that a particular machine owned the connection.

RFC 9850 identifies another missing dependency explicitly. Secret values are not annotated with the cipher suite or other connection parameters, so a record of the TLS handshake might be needed to use them. A key-log file is therefore not even a self-contained decryption transcript. It is one input to a reconstruction.

A syntactically valid three-field line could also be copied, rearranged or generated independently of the capture attributed to it. That does not make real key logs untrustworthy. It means trust must come from collection and corroboration rather than syntax.

The capability is stronger than “read access”

It would be equally wrong to minimize the file because it lacks evidentiary context. RFC 9850's security section is unusually direct: access to included secrets can break both confidentiality and integrity for active connections and for encrypted records stored earlier.

The integrity consequence matters. The keys derived from the logged material are symmetric. An adversary able to remove record protection can, in the relevant circumstances, also encrypt data for an active connection. That can make injection or modification possible. The secret is not merely a window into a session; it can become a writing instrument inside one.

Exporter secrets extend the blast radius beyond readable packets. Applications may use TLS exporters for session bindings, authentication or additional derived secrets. Logging those values can expose an application-layer trust mechanism that is invisible in a network trace considered only as content.

Forward secrecy also stops doing the job operators expect. TLS normally limits the damage from a later long-term-key compromise. Once the relevant traffic secrets themselves are recorded, previously captured records for those logged connections can be decrypted. The archive and the key log become a delayed disclosure system.

The label determines the power. TLS 1.3 separates handshake, application, early-data and exporter material. A TLS 1.2 CLIENT_RANDOM entry carries the connection's master secret, which RFC 9850 says can support reading and alteration, resumption, impersonation of either endpoint, renegotiation insertion and forged Finished messages. An ECH_SECRET can reveal the Inner ClientHello, including the protected SNI. An inventory that stores only “key log present” discards the most important risk distinction.

The production prohibition is an architectural rule

RFC 9850 does not offer a balancing test for ordinary production observability. It says the format is intended for systems where TLS protects only test data and that the mechanism MUST NOT be used in production. For compiled software, it recommends conditional compilation so deployed binaries cannot be configured to enable key logging.

That advice moves the control boundary earlier than a file-permission checklist. If a production binary does not contain the capability, an environment variable, compromised launcher or mistaken runbook cannot turn it on. Access control remains necessary in laboratories, but it is not an adequate substitute for removing a forbidden production feature.

This distinction becomes urgent when debugging language migrates into monitoring language. “Temporary diagnostics” can acquire a permanent directory, automated collector and broad analyst access. A file intended for a single test may outlive the capture, enter a backup and become useful to someone who was never authorized to see the session. The operational question is not only who can read the file today. It is why production code could create it at all.

Discovery in a production estate should therefore be treated as a containment signal, not a configuration curiosity. The operator needs to identify the generating binary and launch context, stop further logging, protect existing files and captures, scope the affected connections, consider exporter-derived dependencies and preserve evidence without spreading the secrets through tickets or chat.

Decryption success and failure both need narrow meanings

A successful reconstruction is useful evidence. It can show that a particular secret derives keys that authenticate and decrypt particular captured records under a particular interpretation of the handshake. It may allow an incident team to identify an application request, protocol error or malicious action that was otherwise hidden.

It still does not prove lawful acquisition. It does not identify the natural person behind a client. It does not show that the capture is complete, that the reconstructed content was displayed to a user or that the endpoint named in an asset database controlled the process at that time. If an analyst can inject into an active flow, the output also needs a boundary between observed records and records created during testing.

Failure is not the moral opposite. A secret may fail against a capture because the wrong connection was selected, the handshake is missing, a key update changed the applicable material, the direction is wrong, ECH selected a different random or the integrated protocol supplied additional context. “Did not decrypt” is a diagnostic result, not proof that the file was fabricated.

The incident record should preserve both attempts and reasons. Otherwise a dashboard compresses a multi-input reconstruction into a green or red verdict and removes the very uncertainty an investigator needs.

The TLS handshake and the key log answer different questions

RFC 9846 describes the TLS 1.3 handshake as negotiating protocol parameters, authenticating peers under the selected mechanism—client authentication is optional—and establishing shared secret keying material. It also leaves application protocols to specify how certificates and TLS authentication are interpreted.

The key log exports selected products of that key schedule. It does not replay certificate validation, state what name the application expected, assert that the client was authenticated or assign a human being to either endpoint. Even when the captured handshake supplies certificates, their meaning depends on validation state, reference identity and application policy that should be recorded separately.

RFC 9325 similarly treats authentication, confidentiality and data integrity as related but distinct deployment goals. A debugging artifact that disables two of them cannot inherit the third as documentary authority.

Heng Lu's Policy Mirror gives the larger discipline: a record may describe reality but does not create it. Running-Code Primacy asks that a common artifact be interpreted only as far as its deterministic function requires. On Reality Layers separates executable effects from symbolic assertions. Here the executable effect is formidable—secrets and captured records can reveal or alter protected traffic. The symbolic overreach is to call the three-field file proof of an entire incident.

Martin Thomson's contribution without borrowed authority

The fairest profile of Thomson is not that he made TLS readable. Implementations and NSS practice predate the RFC, and the document names three authors. His attributable contribution is to a consensus text that makes a deployed convention interoperable while putting its danger in the foreground.

That combination matters. Standards work is sometimes described as permission: once a format has an RFC number and an IANA registry, organizations treat its use as institutionally approved. RFC 9850 says the opposite. Standardization helps tools agree on bytes; it does not turn an unsafe deployment into a conforming production practice.

The document also refuses to flatten secrets into one class. It identifies the different powers of traffic, exporter, TLS 1.2 master and ECH material. That is the vocabulary an operator needs to scope harm rather than merely count files.

Authorship should remain just as scoped. Thomson, Rosomakho and Tschofenig are responsible for the document attributed to them. Implementers decide what they build. Release owners decide what enters production. Operators decide how processes launch. Investigators decide how evidence is collected and interpreted. A published format cannot absorb those decisions.

Build an evidence package around the dangerous file

A defensible diagnostic record begins before decryption. Record the binary and build that exposed logging, the enablement mechanism, the initiating actor and authorization, the process and asset identity, the exact collection interval, file permissions, hashes, storage location and every custody transfer.

Record the traffic separately: capture interface, direction, filter, clock source, packet loss, handshake completeness, transport tuple and hash. Then record the analytical join: which label and ClientHello random matched, which protocol parameters were recovered, which tool and version derived keys, which records authenticated, which did not, and whether the tool performed any active operation.

Finally record the interpretation without letting it inherit certainty. Distinguish endpoint keys from user identity, decrypted bytes from application display, captured request from completed business action, and authorized test from suspected intrusion. Preserve uncertainty and a path for another analyst to reproduce the result without distributing the underlying secrets more widely than necessary.

The key log remains useful after these limits are imposed. It becomes more useful because it can answer its real question without impersonating a court, an identity provider or a complete history.

Sources