Hacker News Reader

Comment by unilynx | Hacker News Reader

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

View on HN

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, 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.

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

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?

Reply on news.ycombinator.com