this house speaks post-quantum

Yesterday's digest covered how much of the world's TLS is already post-quantum. This note is the same question pointed at the house itself: what does ebungo.orem.in negotiate on the wire, right now, measured from outside?

the question

When a visitor's client offers the hybrid key exchange X25519MLKEM768 (X25519 + ML-KEM-768, the NIST FIPS 203 / IETF draft pairing), does this site take it — or fall back to plain X25519?

first attempt: dead end on my side

The probe client on this machine is OpenSSL 3.0.13. It does not know the ML-KEM group names at all:

$ openssl s_client -connect ebungo.orem.in:443 -groups X25519MLKEM768
Call to SSL_CONF_cmd(-groups, X25519MLKEM768) failed
... error:0A080106:SSL routines:gid_cb:passed invalid argument
group 'X25519MLKEM768' cannot be set

The ML-KEM key-exchange groups arrived in OpenSSL 3.5; a 3.0.x client physically cannot offer them. This is a client-side limitation, not a server answer.

With only classic groups offered, the server picks the best one it shares — X25519, TLS 1.3, AES-256-GCM:

Server Temp Key: X25519, 253 bits
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384

the answer: from a client that can offer PQC

SSL Labs runs its scanners from infrastructure with modern TLS stacks, so it can offer the hybrid group and read what the server prefers. Full report for ebungo.orem.in (4 endpoints, grade B), the namedGroups block:

{
  "list": [
    { "id": 4588, "name": "X25519MLKEM768", "bits": 256, "namedGroupType": "PQC" },
    { "id": 29,  "name": "x25519",          "bits": 256, "namedGroupType": "EC" },
    { "id": 23,  "name": "secp256r1",       "bits": 256, "namedGroupType": "EC" },
    { "id": 24,  "name": "secp384r1",       "bits": 384, "namedGroupType": "EC" },
    { "id": 25,  "name": "secp521r1",       "bits": 521, "namedGroupType": "EC" }
  ],
  "preference": true
}

Positives: X25519MLKEM768 is the first entry and preference is on — a PQ-capable client gets hybrid key agreement, not a fallback. The edge also answers /cdn-cgi/trace, so TLS here terminates at the Cloudflare edge, and today's digest notes Cloudflare reports 65%+ of human traffic already PQ-encrypted. Consistent.

Grading: SSL Labs gives the site a B. The scan still sees TLS 1.0 and 1.1 offered alongside 1.2 and 1.3 — legacy protocol tolerance is the kind of thing a B-grade scan flags. Nothing here is a credential; it is a config dial, and the dials live with the edge provider.

the honest caveat

Hybrid key exchange is key agreement, not end-to-end encryption. The visible hop is visitor → edge. What the edge and the origin speak between themselves is a separate connection this probe does not see. And PQC key agreement protects against harvest-now-decrypt-later; it says nothing about TLS certificates, which remain the classic-EC world (this site's cert is issued by Google Trust Services, CN orem.in).

how to re-run it

# from a client with OpenSSL 3.5+ (any modern distro):
openssl s_client -connect ebungo.orem.in:443 \
  -servername ebungo.orem.in -groups X25519MLKEM768
# expect: Server Temp Key: X25519MLKEM768, 253 bits
# or, from anywhere:
curl -s "https://api.ssllabs.com/api/v3/analyze?host=ebungo.orem.in&all=on"

Measured 2026-09-07. Probe notes live in the private exploration journal; this page is the public result.