add probe for TLSv1.3 ECH (Encrypted ClientHello, ESNI replacement)

[eighthave]

I'm working with @sftcd on implementing the TLSv1.3 ECH standard as widely as possible. One thing that would be quite helpful would be to have data on whether anyone is blocking ECH currently. OONI seems like the best platform for that. I've never implemented an OONI probe. I have some funding to pay either myself or someone more qualified to do this.

I believe there is already an ESNI probe so that would be quite closely related.

[bassosimone]

@eighthave that's super interesting! If I understand it correctly, your project/implementation is to add support for that in OpenSSL, am I correct? We are currently mostly using Go code. I know https://github.com/cloudflare/go is a fork of Go that also implements ECH. Could using this be a (maybe not so cheap but certainly quite interesting) way of running these tests with OONI?

[eighthave]

Yes, we have implemented it in openssl, and are following the boringssl implementation. Then we also implement it in clients like curl, lighttpd, nginx, etc. It looks like that fork implements ECH already: https://github.com/cloudflare/go/blob/b0875fbf17405ccd0e3a57ec9fa0614d5e9be13c/src/crypto/tls/ech_test.go @sftcd do you know about how current Cloudflare's Go implementation is?

[sftcd]

On 20/04/2021 17:01, Hans-Christoph Steiner wrote: @sftcd do you know about how current Cloudflare's Go implementation is?

CF are up to date with draft-10. But for ooni you don't need a real ECH just to attempt with a GREASE'd one, so you just need the code-point and about the right number of random octets. S.

[eighthave]

I guess the tricky part is getting access to the TLS transaction at the right place to insert that code-point and random octets

[sftcd]

On 20/04/2021 17:57, Hans-Christoph Steiner wrote: I guess the tricky part is getting access to the TLS transaction at the right place to insert that code-point and random octets

Or just use CF's go implementation? If some specially crafted something were needed I'd be happy to try help with that, but I'd hope that's not the case. S.

…

[eighthave]

I've never done any Go before, so I'm not a great candidate to code this. @bassosimone how can I help make this happen?

[eighthave]

This is still interesting to us. Anything we can do to help? We have lots of example code in C and C++ for example.

[d1vyank]

I am interested in taking this up. Given ECH’s ‘do not stick out’ requirements and attempts by censors to block prior iterations of the protocol (ESNI), I think it is important to test early on if the draft version of ECH is subject to any network interference.

I propose to add an experimental test to probe-cli or miniooni that attempts a TLS connection with an encrypted Client Hello. I’ve looked into the two approaches discussed above:

• Use Cloudflare’s ECH implementation: This approach will require compiling OONI with Cloudflare's Go fork as they have implemented ECH in the standard library, and Go does not permit swapping out parts of the standard library (discussion here). I imagine this will require a new make command that will fetch and compile cloudflare/go and then build OONI with the forked version of Go. We can also use compiler directives to exclude the ECH test when regular versions of Go are used. Once built with the fork, the test can simply use crypto/tls to attempt an ECH connection to a server that supports it.
• Attempt a GREASE’d ECH connection: Since ECH connections are supposed to look identical to non-ECH connections, the protocol allows for a mocked ECH extension with random values to be present in the Client Hello. The test can use a library like refraction-networking/uTLS to get access to the Client Hello during the TLS handshake and insert a mock ECH extension.

I am leaning towards the GREASE approach as it seems like a less intrusive change than using a Go fork. Even though GREASE is not a complete ECH connection, it will provide valuable early evidence of interference to TLS connections using the ECH extension.

Happy to hear your thoughts!

[sftcd]

On 29/07/2022 07:38, Divyank Katira wrote: I am leaning towards the GREASE approach as it seems like a less intrusive change than using a Go fork. Even though GREASE is not a complete ECH connection, it will provide valuable early evidence of interference to TLS connections using the ECH extension.

That makes sense. Happy to provide samples etc if that helps and/or if you're testing against defo.ie, I can look at logs if debugging's needed. One suggestion - when you GREASE you should expect to get a retry_config in return that has a (or some) ECHConfig(s) that the server uses. It'd be interesting to record those and see if they differ from locale to locale perhaps. That'd be most interesting as help in figuring out any interop problems and likely less so in terms of exploring censorship as you should only see the retry_config after the server's authenticated. Happy to discuss more as you get to doing it. Cheers, S.