Encrypted ClientHello (ECH)

[eighthave]

It would be great to have support for TLS Encrypted SNI (ESNI) in Conscrypt, so Android apps can include Conscrypt to get TLSv1.3 and ESNI support. Work is already underway in boringssl and openssl to support ESNI, so it should be relatively straightforward

I'm working with others on implementing Encrypted SNI on services used on Android. ESNI is up to draft4 in the IETF process, so now is a good time to start implementing in order to provide feedback to the IETF process. We're wondering how much interest there is here in TLSv1.3 Encrypt SNI extension that is currently an IETF draft implemented by Firefox, Cloudflare, and others. We could potentially submit code to make Conscrypt support ESNI. We are currently working on getting ESNI implemented in openssl, curl, and lighttpd.

[kruton]

This might be able to be done transparently for clients if hooks are defined for each platform. OpenJDK has the DNS/JNDI and it appears you can query with a target record type of "*" if needed. Android would use its netd resolver most likely.

[eighthave]

Yeah, making it transparent to clients by default sounds ideal, though I suspect there might be good reason expose somethings. DNS is not a requirement for ESNI, just the suggested way to distribute key material. For example, there are some ESNI modes where the keys do not come from DNS, but "somewhere else". For that to be useful, the client needs to be able to provide that key material in Java.

[kruton]

Some notes for possible future implementors:

1. For DNS there are several APIs that allow the SSLSocket or SSLEngine to be created. Some are supplied with resolved addresses and some are not. It is critical that during the DNS fetching of ESNI that the ESNI records and A/AAAA records stay in sync (i.e., whatever chooses the IPv4 or IPv6 for multi-record entries also chooses the right ESNI entry). This is dependent on whether HTTPSSVC/SVCB or CNAME style comes out in the end of the RFC process as the winner.

2. DNS servers in home environments are generally horrible and this might affect performance (e.g., the records may not be able to be fetched at all).

Upstream BoringSSL bug

[davidben]

Small correction to 1, it's not that ESNI and A/AAAA records have to stay in sync (separate record types aren't guaranteed to be in sync). It's that the IP addresses need to come from the ESNI flow, to handle the multi-CDN use case correctly. That means either the ESNI record (which is ESNI keys and addresses stapled in one record) or the HTTPSSVC/SVCB record (which is basically ESNI keys stapled to a funny CNAME), either of which override the usual A/AAAA lookup flow.

Re 2, realistically I expect ESNI will need to depend on DoH or DoT to avoid troubles with buggy router DNS resolvers.

[eighthave]

So @uniqx and I have been putting together a test harness, and started digging into the DNS resolving question. It looks like the place we'll need to change is in the constructors of AbstractConscryptSocket that include a hostname, or a subclass of that. Specifically, the AbstractConscryptSocket constructors's call to super() end up instantiating an InetAddress instance, which would do the DNS resolution. The method that overrides Socket.connect(SocketAddress, int) would also need to do this.

But it looks like perhaps it should happen at a higher level, in the ConscryptEngineSocket constructors, where there is already SSLParametersImpl, which would then have an instance to manage the ESNI keys, like ESNIKeyManager. We are not entirely clear yet which level makes sense.

Then ESNIKeyManager could be exposed for the use cases that need to provide key material themselves, and skip the built-in DNS lookup.

[davidben]

You need to be very careful here because of the multi-CDN problem. The ESNIKeyManager idea probably won't fly. At least in the direction things are flying, lots of aspects of the DNS lookup are being correlated together. They're also very much in flux right now as we figure out how this should work. (TBH, I think it's trending too much in the complex direction, but it'll be hard to reel it back in. DNS loves deployment flexibility and pushing complexity off to the client.)

[eighthave]

ESNIKeyManager is a bad name for what we are proposing here. It would be something like what @sftcd did in his openssl API, where there is a list of valid keys stored in SSLParametersImpl. So not a manager at all, but more like ESNIKey[] ValidESNIKeys. Or perhaps a class that provides some kind of query method to get the right key based on provided criteria.

[davidben]

Right, it's the query mechanism that is you need to be careful with.

[eighthave]

Do you have any concrete examples we can work with? It would be good to have that in a test case as we work on this.

[Fezravien]

Excuse me.
I wants to know ESNI something.

Can you tell me how to manage the key to encrypt the sni?
Is it managed between web server and dns server?

If yes, what do you think about the key renewal?

[eighthave]

Right now, we're starting with HTTPSSVC as the DNS method for getting the ESNI key material. @davidben @kruton do either of you have specific thoughts or requirements on which DNS records Conscrypt should support by default? Like whether Conscrypt should only do HTTPSSVC by default or also handle generic SVCB requests?

Also, I guess the idea is that Conscrypt would handle the DoH/DoT detection. Or will Android provide some method for that?

[eighthave]

Android provides LinkProperties.isPrivateDnsActive() and LinkProperties.getPrivateDnsServerName(), for detecting DoH/DoT. OpenJDK does not seem to have anything similar. So we would need to abstract that piece in order to use this detection in ConscryptEngineSocket