Comment by agwa | Hacker News Reader

Comment by agwa | Hacker News Reader

Since there are several questions about Encrypted Client Hello (ECH), and I kind of hand waved that section, I thought an example might be useful.

Let's say the system is running two web server daemons: a multi-tenant blog hosting platform listening on 2001:db8::1, and a multi-tenant bug tracker listening on 2001:db8::2. snid is on 192.0.2.1. Your DNS records would look like this:

  blogs.example.com. A 192.0.2.1
  blogs.example.com. AAAA 2001:db8::1
  bugs.example.com.  A 192.0.2.1
  bugs.example.com.  AAAA 2001:db8::2

The various tenants would be CNAMEd to one of these hostnames like:

  blog.domain1.example. CNAME blogs.example.com.
  bugs.domain2.example. CNAME bugs.example.com.

The "decoy" hostnames (the "public_name" in ECH parlance) would be blogs.example.com or bugs.example.com. Thus, ECH would hide which tenant the client is connecting to, but would not hide the service. Note that if the client were connecting over IPv6, an eavesdropper would be able to determine the service anyways by looking at the destination IP address, which is unencrypted.

Note that if you wanted to provide privacy protection for the encrypted SNI, you'd have to have a single external-facing IPv6 address too, not just IPv4. Then, of course, you couldn't steal enough bits to represent the client address in the source address presented to the backend. Tricky. You might have to implement the PROXY protocol after all. Another option might be to do something like identd for established TCP connections, and interpose on getpeername() on the backend side to call the identd at the proxy.

Nice solution. You can got a step further if you have the need - your eavesdropper or malicious observer problem can be addressed by launching the network connections from inside the process space of your app, e.g. for golang: https://github.com/openziti/sdk-golang

Similarly, this eliminates the IP address dependencies.

Sample (Java in this case - see GitHub above for various language options): https://blogs.oracle.com/javamagazine/post/java-zero-trust-o...

Would it be accurate to summarize this way?

TLS + ECH encrypts all message content, including the client hello with the hostname, but it does not encrypt a specific message (an IP address + service identifier combination) that uniquely specifies which program will terminate the TLS connection.

If you want information to be private about the host name you're connecting to, you need not only a single public IP address for many hosts, but also for that server to terminate TLS for all of those hosts.

That's an accurate summary of how TLS+ECH would work with snid.

More generally, I don't think it's required for a single server to terminate TLS for all hosts. If an SNI proxy server knew the private key necessary for decrypting the ECH extension, it could look inside it to determine where to proxy the connection, without having to terminate TLS.

If snid worked this way, the unencrypted SNI hostname wouldn't need to identify the backend, which means that clients connecting over IPv4 would have more privacy. But snid would have to coordinate the ECH encryption key with the backends, which would add a lot of complexity, and IPv6 clients wouldn't benefit in any case.

> That's an accurate summary of how TLS+ECH would work with snid.

snid or not, ECH doesn't function much different to domain fronting, does it?

Reply on news.ycombinator.com