Hacker News Reader

Comment by ameshkov | Hacker News Reader

Can anyone explain why is it designed this way? Why was it necessary to involve DNS into this? Was it unavoidable or is that all in the name of keeping 0-rtt possible?

Tbh, with the current implementation, ECH setup seems rather complicated to me. It benefits CDNs like CloudFlare since they control both DNS and the handshake process, but those who would like to setup ECH on their own are in trouble.

View on HN

You need to know if you're talking to the server you think you're connecting to, otherwise a man-in-the-middle could impersonate the server and intercept the handshake to see the hostname you're trying to connect.

So you need another channel to pull a public key (or something comparable), and they picked DNS for that

As someone suggested in a different comment: handshake with one certificate, then send a new ClientHello that contains the desired hostname and "re-handshake" with the real cert?

How do you validate the authenticity of the first certificate without revealing any hostnames?

If we're keeping this simple, then I'd say have IP address in subaltnames. Obtaining such certs shouldn't be a problem for CDNs, and possible for others as well (regarding free options: Let's Encrypt doesn't support that, but ZeroSSL does)

You wouldn't even need a cert for an IP address (which is hard to get). You could just resolve the CNAME and A records until you arrive at an address, do a reverse lookup on that address. Then use the resulting "primary" PTR hostname for the encryption certificate. No additional info for an attacker, no new weird RRs, in the best case just one additional DNS query (but SVCB would need that as well).

That means one-site-per-IP, which doesn't work with the way we currently do L3->L5.

One-site-per-IP also ruins much of the point of ESNI, since then anyone who wants to block or track what domain you are visiting can just lookup the domains they’re interested in and match them to IP addresses.

For the most part they can do that anyways, ESNI or ECH are only relevant for big hosters or proxy services.

no, the per-ip key is just the one you would use for ECH, in the encrypted part you can use separate per-vhost certificates as usual

No, this is just a way to verify the Cert for the first handshake, so that one doesn't need to use one with the IP in the sub alt names.

That would require coordination with a certificate authority any time your IP changes, which could be very inconvenient in some cases.

Meanwhile, DNS records already need to be updated if your IP changes anyway, so it is a logical place to put the authenticity information

How do you know that the first certificate was not produced by the MitM?

In order to encrypt the connection handshake, you and the server need to agree on a key to encrypt it with.

If you do the key exchange on the connection, you have two choices:

a) anonymous key exchange, which could be MITM, because it's unauthenticated. This would be more secure than just sending the hostname in plain text, because it would require active interception rather than passive surveillance, but active interception is not that much harder than passive surveillance.

b) signed key exchange, which is tricky, because the server may have certificates for many hostnames, and it doesn't know which one you used

In order to have another option, you need to get a key through some other method. DNS is the more or less the most viable out of band method to get that information; after all, it's what you used to turn a hostname into an IP address to contact the server in the first place.

You could do (a) to force active attacks, and then at the end (after SNI) authenticate the server based on the then-matching cert, followed by checking that you both got the same symmetric key from the ECDH key exchange at the beginning. If they don't match, you know there was an active MITM and both sides know.

The client initiates the connection and must know a key to encrypt the client hello with before the first packet. Unsigned DH is out because that would allow MitM and involve another roundtrip, cached certificate is only known on the second connection and hardcoded keys would be stupid. That leaves DNS.

Reply on news.ycombinator.com