implement real Encrypted ClientHello probe

[johnhess]

Draft

This implements a real ECH probe using go 1.23.4* which implements Encrypted ClientHello (client-side) in its tls package.

We use the native tls implementation to execute the handshake and borrow the ECH Config parsing code from golang's own implementation in order to capture appropriate values from the config for our ArchivalTLSOrQUICHandshakeResult.

To try it out, run

go run ./cmd/ooniprobe/main.go run experimental --no-collector

and watch the lines that begin with echcheck

*More precisely, this wants to use an even newer version of golang which includes 858a0e9dfd, since that will provide retry configs:

* 858a0e9dfd - crypto/tls: properly return ECH retry configs (11 days ago) <Roland Shoemaker>

It will run with 1.23.4, but GREASE connections will fail to establish a TLS connection. As a result some tests will also fail under 1.23.4.

[johnhess]

Next steps:

• Determine whether HTTPS DNS records are being blocked (add a DNS probe, possibly hardcode the RRs)
• [Blocked, see comment] Determine whether we get retry configs with GREASE'd ECH (improvement to the probe as is)
• Probe multiple ports
• Ensure appropriate test coverage. Given this is a probe-in-waiting for probe-cli's golang 1.23.4 upgrade, I'll make sure this is worth doing up front.
• Remove utls as a dep.

[johnhess]

Watching for retry_configs seems to involve updating utls or reinventing a portion. Asked in Slack #ooni-dev abou that:

It looks like the utls version probe-cli uses was last updated about 4 years ago. Are there broader plans/discussions on whether probe-cli will eventually update to a more up to date fork like the refraction-networking one? I am personally interested in it for an Encrypted Client Hello probe in which I’d like to observe whether or not we get retry_configs from the server in response to a GREASE’d ECH. The newer fork has that field and I’d like to not have to reinvent any wheels.

[johnhess]

ooni is trying to remove utls as a dependency (see WIP PR) and as such we want to explore alternative approaches to inspecting the gory details of the TLS connection, then decide on and implement one of those.