Key exchange
- Group
- secp384r1
This is the single field that decides whether a recording of your session survives a quantum computer. Everything else on this page is about who you are, not how long your secrets last.
CLASSICAL
Classical key exchange
Your client negotiated a classical group. This connection is secure against today's adversaries, but a recording of it is decryptable by a sufficiently large quantum computer — the "harvest now, decrypt later" exposure.
Encrypted Client Hello
ECH unavailable on this listener
This connection was served by the OpenSSL listener, which holds no ECH keys. That is a property of the port you reached, not of your client.
Our ECH config list is published in the DNS HTTPS record for pqcrypta.com and rotated on a timer, with previous configs retained so clients holding a cached record still complete.
Transport & TLS
- Protocol
- HTTP/2 over TCP
- TLS version
- TLSv1.3
- Cipher suite
- TLS_AES_256_GCM_SHA384
- ALPN
- h2
- Terminated by
- OpenSSL 3.5
Your fingerprint
- JA4
- t13d1114h2_5e2a75874763_352e3a9193bf
- JA3
- 0a84269fcc8452ac11db9e0d0b6728db
- Classified as
- not in our database
A JA4 is a hash of how your TLS client is built — its cipher list, extension set and ordering — not of anything you sent. Two people running the same browser build share one. Look yours up in the directory.
Session properties
- 0-RTT early data
- not offered
- Client certificate
- none presented
- Observed at
- 2026-09-10T04:40:40+00:00
0-RTT lets a resuming client send its request in the first flight, before the handshake finishes — at the cost of that request being replayable. Routes here declare whether they accept it; the ones that do not answer 425.
JSON
The same data, for scripts and CI. No auth, no cost, CORS open — the response only ever describes the caller's own connection.
curl https://pqcrypta.com/handshake/api.phpUseful as a regression test: assert .facts.key_exchange.post_quantum == true after a TLS library bump and you will know the moment your client stops negotiating ML-KEM.
Why this page can exist here
Most of what is above is knowable only by the machine that terminated your handshake, and only if that machine is doing unusual things. Three of these fields are the unusual ones.
The key exchange group is reported by plenty of servers. What is rare is that this one will actually negotiate a post-quantum group with you — X25519MLKEM768 via OpenSSL 3.5 with native ML-KEM — rather than telling you which classical curve you got.
Encrypted Client Hello is the rare one. Terminating ECH means holding HPKE keys, publishing the config list in a DNS HTTPS record, rotating it, and retaining old configs long enough for cached records to expire. Outside a small number of large CDNs, almost nothing on the public internet does this, which means almost nowhere can tell you whether your ECH attempt worked — only whether it appeared to.
The JA4 is computed from your ClientHello bytes before the handshake completes, which a server only has if it is inspecting them itself rather than handing the socket to a TLS library and taking the result.
What this page will not tell you
Nothing, now. Three fields used to come back blank over HTTP/3 — the cipher suite, the key exchange group, and the Encrypted Client Hello outcome — and this page said they were "not observable over HTTP/3". That was true of the code and false of the protocol. ECH is a TLS 1.3 extension and QUIC is TLS 1.3, so the same handshake resolves it either way; the result simply had no route up to the application. An HTTP/3 visitor on a post-quantum connection was being told their connection was unmeasured.
All three now come through the QUIC handshake data, so an HTTP/3 visitor gets exactly the same answer as an HTTP/2 one. Where a field is genuinely absent, this page still says so rather than inventing a plausible value — but "the protocol cannot show this" is a claim worth checking before it is written down, because it is usually a claim about the code.
Every value here is asserted by the proxy after its own handshake, and every
one of these headers is stripped from your request before being set, on all
three listener paths. You cannot make this page claim a handshake you did not
have by sending the header yourself — try it. Two of them
(x-client-type, x-client-name) were briefly an
exception: they are set only when the fingerprinter has something to say, and
a conditional insert with no strip let a caller assert them. They are stripped
unconditionally now, like the rest.