Encrypted SNI or ClientHello

[yschimke]

tracking bug

Boring SSL - https://bugs.chromium.org/p/boringssl/issues/detail?id=275

Conscrypt - google/conscrypt#730

Reference from Tunnel Bear to contributions to enable for OkHttp (seems blocked)
https://www.tunnelbear.com/blog/tunnelbear-implements-encrypted-sni/
https://boringssl-review.googlesource.com/c/boringssl/+/42644

Now ECH - https://blog.cloudflare.com/encrypted-client-hello/

[Luxusio]

When will the feature be added?

[yschimke]

No current plans and waiting upstream for support. If you need it I suggest patching Conscrypt with the attached links above.

[eighthave]

I'm just starting to work on implementing ECH in Conscrypt, once boringssl supports ECH client-side. I'll track progress in google/conscrypt#730

[yschimke]

@eighthave Great, let me know how it's going, I'm keen to add support for this with Conscrypt to OkHttp.

[eighthave]

Ok, good to know! Have you looked into ECH much yet? One key piece that I'm interested in is making sure that client libs like Conscrypt and OkHTTP have a good API for providing the ECH public key material. This means something that works without DNS. While DNS serves the majority of the cases well, ECH does not require DNS, and there are many important, minority use cases that are only possible if there is a way other than DNS to provide the required public key material. We can start thinking about this and working out the API now, since the spec is getting close to RFP, and there are already implementations that provide something similar, like our (DeFO's) curl implementation of ECH that we are working on upstreaming.

[yschimke]

Does DNS over HTTPS help here? Overall I'm hoping that 80% of complexity is in BoringSSL, 15% in Conscrypt and 5% in flipping a switch in OkHttp's ConscryptProvider, or prior to explicit calls to socketFactory and sslSocketFactory.

[eighthave]

There are use cases where the site operator does not want to publicly advertise a specific setup, so they want to keep that info out of DNS. Anyone can query DNS, so its public info. For example, if a company wants to provide tunneling services via their website for employees traveling to places where VPNs are blocked. Or ideas like MASQUE in IETF.

So yes, 80% of the compexity will be in boringssl, then most of the rest in Conscrypt. OkHTTP should just expose the Conscrypt API for feeding ECH key material, etc. This is likely dead simple, for example, like this in curl:

curl --echconfig \
  AEL+CgA+8QAgACCsEiogyYobxSGHLGd6uSDbuIbW05M41U37vsypEWdqZQAEAAEAAQAAAA1jb3Zlci5kZWZvLmllAAA= \
  https://draft-10-echonly.esni.defo.ie:9410/

[eighthave]

So I have ECH working in Conscrypt at the most basic level, now I'm looking for feedback for how to best implement the API for getting the ECH Config List bytes through Conscrypt into boringssl. There are just two things needed:

• A method to pass in byte[] echConfigList that matches a given URL
• A method to enable/disable ECH GREASE at least on the global level, but maybe also per connection.

I'm not familiar with how OkHTTP is implemented. Does OkHTTP already have the ability to do arbitrary DNS query types? Otherwise https://github.com/dnsjava/dnsjava already has ECH support implemented. Either of those options are needed to start working with HTTPSSVC / SVCB DNS queries to get the ECH Config List. The TLS client gets the ECH relevant public keys from the ECH Config List. Right now, I'm thinking that the ECH Config List and ECH GREASE set via the javax.net.ssl.SSLParameters.

[yschimke]

OkHttp doesn't do arbitrary DNS queries. Is either uses the system default DNS, an application provided one, or a very minimal optional DNS over HTTPS implementation that only handles A and AAAA queries.

So you could either use dnsjava, or potentially fork DnsOverHttps to add extra query types and see whether it is clean enough to fold back in. I suspect this PR should start as a custom Dns implementation and SSLSocketFactory, without changing OkHttp initially. I assume as part of the DnsOverHttps get the key, then configure the Conscrypt socket factory to set the ClientHelloOuter and ClientHelloInner.

Do you have a PR for the conscrypt code and example usage? Have the indicated they are likely to take the PR?

I'd personally love to see this happen, but it will have a much higher chance of working in OkHttp if it can be supported cleanly as an additional module with the existing public API. If it drives a truck through the TLS client code then it will be a hard sell.

[eighthave]

I'm not quite up to a pull request, but soon. I want to implement some of the ECH retry/error handling first. You can see my code here: https://github.com/eighthave/conscrypt Check the EchInteropTest for working examples.

[yschimke]

That sample looks quite clean. It might be interesting to incrementally enhance the DnsOverHttps implementation to cache the keys as a side effect and wire it up to your custom solution socket factory.

[eighthave]

Is using DnsResolver.rawQuery() an option here? In theory, it would allow the required DNS to happen using the device's system resolvers.