Observe and optionally enforce post-quantum key exchange on the origin leg

[ralyodio]

What prompted this

A question about whether the Moshpit stack could do quantum-safe E2E "instead of SSL". Checking the code turned up something better than a rewrite: on the leg that matters, it already is — and there was no way to tell when it wasn't.

The measurement

moshpit-proxy configures no TLS groups anywhere; the origin leg uses Node defaults. On Node 24 / OpenSSL 3.5 those defaults already offer the hybrid first. Read off the wire from the ClientHello the proxy actually sends:

supported_groups: X25519MLKEM768, x25519, secp256r1, x448, secp384r1, ...
key_share sent  : X25519MLKEM768(1216B), x25519(32B)

So harvest-now-decrypt-later is already defeated on the browser path — provided the origin is also on 3.5+.

The actual gap

An origin on OpenSSL 3.0–3.4 (what Ubuntu 22.04 and 24.04 ship) has no ML-KEM. The handshake silently falls back to x25519 and succeeds. Nothing logged it, nothing counted it, nothing could enforce against it. A guarantee nobody can observe isn't one.

What this adds

• lib/pq.ts — classifies the key exchange on the upstream leg.
• Every upstream leg counted: pqSessions / classicalSessions / refusedClassical, printed at shutdown, with a warn line per fallback.
• MOSHPIT_PROXY_REQUIRE_PQ=1 turns fallback into a refusal. Off by default — switching it on today takes every pre-3.5 origin offline. The counters are how you find out when it's safe to flip.

The one subtle part

Node exposes no binding for SSL_get_negotiated_group(). What it has is getEphemeralKeyInfo(), which goes through SSL_get_peer_tmp_key — that call can't represent a hybrid KEM, so it returns {}, while any classical group comes back named. That inverts into a usable signal:

getEphemeralKeyInfo()	means
{}	PQ hybrid
{ type, name: "X25519", size }	classical

Inferring a positive from an absence is fragile — a future Node/OpenSSL that teaches SSL_get_peer_tmp_key about ML-KEM would silently invert the meaning. So it's proven, not trusted: probeDetector() runs two loopback handshakes at startup, asserts both halves of the mapping, prints the result, and enforcement refuses to engage if the proof fails.

[proxy] post-qm  X25519MLKEM768 offered to every origin, observed only
[proxy]           verified: X25519MLKEM768 reads as hybrid, X25519 reads as classical

Testing

35 pass (27 existing + 8 new), tsc --noEmit clean under strict. New tests cover both halves of the detector mapping, the unconfigured-default case, and end-to-end proxy behaviour against an origin pinned to a classical group — passing when requirePq is off, refused when on.

Not addressed here

Swapping the browser path to MTP/1 outright. The gateway routes on $ssl_preread_server_name and MTP/1's buildClientHello() takes no arguments — it carries no name at all. That's a real design fork, noted in the conversation, not something to smuggle into this PR.

🤖 Generated with Claude Code

[github-actions]

vu1nz Security Review

0 finding(s) in PR #?

No security issues found.