Checking whether a TLS connection actually negotiated X25519MLKEM768

Goal

Status as of 25 October 2026. Establish which key-exchange group a particular TLS connection selected. Re-check the deployed library's group defaults, browser policies and TLS termination configuration after upgrades. X25519MLKEM768 combines classical X25519 with ML-KEM; its presence in a configuration is a capability claim, not a connection result.

Prerequisites

Use an endpoint you administer, its DNS hostname, and its normal certificate trust store. OpenSSL's 3.5 documentation records ML-KEM support and a default hybrid key share. Chromium's Q4 2024 report records ML-KEM enabled by default from Chrome 131 on the listed platforms. Both endpoints must support a common group; explicit settings can change the outcome. These are feature baselines, not recommendations to install old releases.

Steps

1. Record the client build, destination, time and network path. Check whether the connection ends at an application, reverse proxy or inspection gateway. Treat each separately terminated leg as a separate inventory item.

2. In Chrome DevTools, open the Privacy and security panel and select the relevant origin under Security. Inspect its connection details and record the key-exchange group if shown. A certificate view or a generic secure-connection indicator is insufficient. The cited panel documentation was last updated on 27 February 2025; labels can change between builds.

3. With a suitable OpenSSL build, make a fresh connection in an interactive terminal using its defaults. Replace the example hostname throughout:

   openssl s_client -connect service.example:443 -servername service.example \
     -tls1_3 -verify_hostname service.example -verify_return_error -brief
   

   Wait for the handshake summary, record the negotiated group and certificate-verification result, then close the probe with Ctrl-C. Repeat with -groups X25519MLKEM768. Successful completion with that sole group establishes support on the tested path. It does not establish what ordinary clients select. Supply the appropriate CA file for a private trust domain; retain hostname verification.

4. Check curl --version for its TLS backend. For an OpenSSL-backed build that supports the group, compare an ordinary request with:

   curl --verbose --tlsv1.3 --tls-max 1.3 --curves X25519MLKEM768 \
     --output /dev/null https://service.example/
   

   Curl's group override replaces the backend's default list. Preserve certificate checks and inspect the handshake result; a failure alone cannot distinguish unsupported groups from unrelated connection problems. Do not assume every backend prints the same diagnostic fields.

5. Correlate the connection with server telemetry. Where available, log the selected group rather than the configured or offered list. OpenSSL exposes SSL_get_negotiated_group() for this purpose. If the server has no such telemetry, record the gap instead of interpreting cipher-suite names as group evidence.

Expected result

The record distinguishes default selection, forced-group support and unverified paths. Keep certificate authentication and key exchange as separate findings. Re-run both checks after changing a group restriction or upgrading a TLS terminator.

Limits and test basis

This is a documentation-based procedure; no endpoint measurements are claimed. A browser connection and a TCP command-line probe can traverse different paths. Session reuse can also obscure a fresh exchange. OpenSSL documents that larger hybrid key shares can expose faulty middleboxes. Diagnose those failures before accepting a permanent classical-only exception.