The Negotiation You Never Logged: Making PQC State Visible in Production
An organisation enables hybrid post-quantum TLS and its monitoring dashboard continues to show successful TLS 1.3 connections. But did those connections use X25519MLKEM768 or classical X25519? Did the hybrid attempt fail before an application retried classically? Did a proxy terminate the external connection and hide the negotiated group from the backend? Most ordinary TLS logs cannot answer these questions.
This talk examines three connections that produce the same “TLS succeeded” event while reaching different security outcomes: successful hybrid negotiation, intentional classical negotiation, and a failed hybrid attempt followed by a classical retry.
Using prepared OpenSSL output, packet-trace excerpts, log comparisons and protocol diagrams, the session explains the difference between required, attempted, negotiated and final cryptographic state. It then presents a practical event model for recording the selected group, runtime provider, failure category, retry decision and policy result.
Attendees will learn how to verify whether PQC is actually being used, detect silent classical exceptions and define migration success through policy satisfaction rather than connection success. No live demonstration, quantum-computing theory or lattice mathematics is required.
Post-quantum migration is difficult to operate when existing monitoring reports only that a TLS connection succeeded. A typical TLS event may include the protocol version, cipher suite, peer identity, latency and HTTP status while omitting the key-exchange group and the decisions that produced the final connection.
That omission becomes important during hybrid deployment. A connection using X25519MLKEM768, one using classical X25519, and one established only after a failed hybrid attempt may all appear as successful TLS 1.3 sessions. The monitoring system looks healthy even though these connections provide different levels of protection and may not satisfy the organisation’s intended policy.
This talk follows three connection paths using OpenSSL output, packet-trace excerpts, structured logs and protocol diagrams. It explains four states that are often collapsed into a single success event:
- The cryptographic mode required by policy
- The group attempted by the client
- The group negotiated for the connection
- The final mode used after any retry or exception
The session also examines where this information disappears. A TLS-terminating proxy may know the negotiated group while the backend sees only an internal request. A client may open a second connection without preserving its relationship to the failed first attempt. Differences in OpenSSL versions, providers or runtime configuration may affect algorithm availability while the application continues to record only that TLS succeeded.
The defensive section presents a practical event model for observing PQC migration. Useful records should include the required policy, attempted and negotiated groups, runtime or provider information, failure category, retry decision, final security mode and whether the result satisfied policy. Temporary classical exceptions should also include an owner, reason and expiry rather than becoming permanent invisible behaviour.
These fields are then mapped to integration tests and operational alerts. Examples include rejecting a deployment when negotiated-group information is unavailable, alerting when a hybrid-required endpoint completes classically, and distinguishing an approved migration exception from an untracked fallback.
The session is intended for developers, platform engineers, network-security teams and defenders who understand basic TLS but are not PQC specialists. It does not claim a new TLS vulnerability, a defect in OpenSSL or evidence from a production security audit. Instead, it translates practical TLS and PQC integration behaviour into an observability model that engineers can apply to their own migration plans.
I’m a Systems & Cryptography Engineer with a background in Political Science and Esports, which shaped my research mindset. I started as a Python backend engineer working with Django, APIs, and application architecture, then gradually shifted toward security, systems, and cryptography to understand how software behaves beneath the surface. Today, I work mainly with Rust, along Python with and C++, focusing on protocol experiments, cryptography, and security-oriented systems.