Build Conscrypt with ECH, and test it on the JVM and on Android

[yschimke]

network:echTest cannot pass on the JVM. Saying so is less useful than saying why, and the answer turns out to be smaller than the red result suggests.

What's actually in the way

What	Where	Status
A TLS stack that can encrypt a client hello	Conscrypt google3-export	Exists, unpublished — built here
Handing the config list to that stack	OkHttp ConscryptPlatform.configureTlsExtensions	Takes an echConfigList and ignores it
Reading a server's retry config back	Conscrypt OpenJDK Platform.wrapEchRejectedException	Discards the retry configs and the public name

Only the middle row is OkHttp's, and it is one call next to the ALPN one — Android10Platform is the model, and it's what lysine-dev/okhttp#9559 does.

conscrypt/

Conscrypt.setEchConfigList(SSLSocket, byte[]) is public API on google3-export and in no release. (google/conscrypt#1406 is still open; what landed on that branch is Google's internal version, exported by Copybara.)

build-conscrypt.sh builds it against a pinned BoringSSL. The build takes several minutes (about six on CI) and its output changes only when pinned.properties does, so it doesn't run per checkin: the conscrypt workflow builds it and publishes the jars as a release tagged with both shas, and the suites download that. Bumping a pin invalidates the cache by construction — the tag no longer exists, so the next run builds and publishes it. A pull request touching the pin gets the build checked and nothing published.

network/build.gradle.kts picks up conscrypt/build/dist/conscrypt-openjdk-*.jar if it's there and leaves the suite out of the source set if it isn't, so neither the fetch nor the build is on anyone's critical path.

network:echConscryptTest

Two suites, both gated on that jar.

EchClientHelloTest connects to a local socket that accepts and says nothing, reads the client hello, and asserts the name is not in the bytes. No DNS, no server, no internet — it's the one ECH result that is never about somebody else's uptime. Verified locally: encrypted_client_hello present, outer SNI is the public name, inner name absent from the cleartext.

EchConscryptTest is EchTest's cases against the public servers with the two things the JVM lacks supplied from outside OkHttp: this Conscrypt, and a network security policy saying ECH is allowed (on Android that comes from network_security_config.xml; the JVM default is a value Conscrypt reads as "no"). The gap between it and echTest is then the second table row and nothing else.

Neither claims OkHttp does ECH on the JVM. The suite makes the setEchConfigList call itself, from a socket factory, precisely because OkHttp doesn't. The third table row has no counterpart at all — on OpenJDK a rejected config throws its retry configs away and nothing public exposes them, so stale.tls-ech.dev can be detected there and not recovered from, whatever OkHttp does.

Android

PublicEncryptedClientHelloTest runs EchTest's public-server cases on the API 37 emulator, so the JVM and Android rows of the status page become the same assertions against the same servers with only the TLS stack differing. It runs first and does not fail the job, for the reason nothing in network gates; the fixture suite after it still does. run-ech-test.sh moves each run's XML aside so both are uploaded.

Two things had to be fixed before that suite could say anything, both found by reading a green job rather than trusting it:

• The first run reported zero tests. The APK install had raced the emulator's package service and got Broken pipe, which is the worst failure available here — not an ECH result, and not visibly distinguishable from a pass on the status page. run-ech-test.sh now waits for pm to answer before the first suite (sys.boot_completed is already true when the install fails, so it's the wrong thing to wait on) and retries any run that writes no results.
• The second run got as far as executing, and all six cases failed identically on Unable to load PublicSuffixDatabase.list. On Android that list is an asset, shipped by okhttp-android, which this module didn't depend on because nothing in its source names it — and DnsOverHttps consults it on every query to decide whether a host is private. So the suite failed before opening a socket. Fixed by adding the dependency; verified by finding assets/PublicSuffixDatabase.list in the assembled test APK.

Verified

• Conscrypt d65d6b6 built against BoringSSL 3c31f33, x86-64 and aarch64.
• network:echConscryptTest → EchClientHelloTest passes.
• Source-set gating checked both ways: no jar, and OkHttp 5.4.0.
• android-ech:compileDebugAndroidTestKotlin passes; the androidTest APK packages the public suffix asset.

The public-server assertions could not run where this was developed — outbound TLS is intercepted there, so the preflight skips them. What the six Android cases say about ECH on API 37 is a question the next CI run answers; the two runs so far never got far enough to ask it.

All of conscrypt/ should be deleted the day Conscrypt ships ECH.

🤖 Generated with Claude Code

https://claude.ai/code/session_01CqiK79k9uoWsn2AzgXpHMA

---

Generated by Claude Code