Test the case where ECH is not configured, which is the one that breaks users

[yschimke]

Closes #22 — the last open bullet on it, GREASE. Progresses #5.

A client that supports ECH sends the encrypted_client_hello extension even with no configuration for the name, so that a handshake using ECH and one not using it look alike on the wire. The failure that reaches real users is therefore not ECH breaking: it is a middlebox objecting to the extension and breaking a handshake from a client that was never trying to use ECH at all.

The public half

EchGreaseTest asks that directly, and unglamorously: an ordinary OkHttpClient — no ECH configuration, no DoH, nothing arranged — fetches from each public server that speaks ECH, and each has to serve it. It runs on every platform rather than only where ECH works, which is the point: the JVM cannot do ECH today, and that must not stop it reaching servers that can. No version gate and no Conscrypt, because it asserts nothing needing either.

Each case also requires the server to say ECH was not used:

Server	The server's own words
cloudflare-ech.com/cdn-cgi/trace	sni=plaintext
tls-ech.dev	You are not using ECH
defo.ie/ech-check.php	SSL_ECH_STATUS: not attempted

Without that the success would be ambiguous — a run where ECH had quietly started working would pass while measuring something else entirely. The marker is the server's wording rather than a header we impose, so a server that changes it fails loudly here instead of silently asserting nothing.

The local half

test-server's /tls now reports the ClientHello's extension IDs, in order — most of what a JA3 or JA4 fingerprint is computed from. The extensions' contents are parsed away by crypto/tls and stay unreported, so this still answers what OkHttp offered rather than exactly how a CDN fingerprints it; the README says so. GREASE values (RFC 8701) are named as such rather than left as sixteen mystery hex codes, and 0xfe0d is called out on its own as encryptedClientHelloOffered — "offered", because whether it was real or GREASE is deliberately invisible from the server side.

ClientHelloExtensionsTest gates on the fixture's own consistency: the list is recorded, it carries the two extensions no TLS 1.3 handshake can omit (server_name, supported_versions), and the ECH flag agrees with the list it was derived from. What OkHttp itself offered is recorded, not asserted — today's JVM offers no ECH extension at all, and pinning that would turn the feature arriving into a failed test.

Verification

• EchGreaseTest run live: all three servers pass, on the pinned release and on 5.5.0-SNAPSHOT.
• go test ./... green. The new Go test covers the extension naming, including the GREASE bit-pattern and a near-miss that must not match it, and asserts Go's own client offers no ECH — so the flag's false means "not offered" rather than "never looked".
• ClientHelloExtensionsTest needs Docker, which this environment doesn't have, so CI is its first real run. Its parsing was checked against a genuine /tls body from the server running locally: 12 extensions recorded, both required ones present, flag consistent with the list.

---

Generated by Claude Code