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
- t13d1011h2_61a7ad8aa9b6_861bc38b0be4
- JA3
- 9b3f4d87c97dd5854d7669a1ceb7bff6
- 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-08-22T18:38:23+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
One field still comes back blank over HTTP/3: the Encrypted Client Hello outcome. The QUIC stack does not surface ECH state to the application, and showing you a plausible value there would be inventing one.
The cipher suite and key exchange group used to be blank here too, and this page said they were "not observable over HTTP/3". That was true of the code and false of the protocol — the stack simply never handed them up, so an HTTP/3 visitor on a post-quantum connection was told their connection was unmeasured. Both now come through the QUIC handshake data, and an HTTP/3 visitor gets the same real verdict as an HTTP/2 one.
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.