← Back to context

Comment by johnisgood

6 days ago

Wait, so you do not leak the host through DNS with this? I have not checked it out yet.

Encrypted DNS has existed for quite a while now through DNS over HTTPS, the missing link was that to connect to a website, you first had to send the server the hostname in plaintext to get the right public key for the site. So someone listening on the wire could not see your DNS requests but would effectively still get the site you connected to anyway.

The new development (encrypted client hello) is you no longer have to send the hostname. So someone listening in the middle would only see you connected to an AWS/etc IP. This will make blocking websites very difficult if they use shared services like cloudflare or cloud VPS hosting.

  • > blocking websites very difficult if they use shared services like cloudflare or cloud VPS hosting.

    I see this as a very good development and a big win for privacy. I have been running my own DNS server for years to prevent passive logging, but could basically do nothing against the SNI leak.

  • > This will make blocking websites very difficult if they use shared services like cloudflare or cloud VPS hosting.

    Until some clueless judge orders all of cloudflare to be blocked.

    • True!

      Though I worry that instead western governments will beat the judges to the punch and start asking things like DNS providers or even HTTPS servers to keep logs that can be subpoenaed much like a telecom company keeps a log of each phone call ("metadata"), or else be blocked...

      1 reply →

In principle, it means you could run multiple sites from the same IP and someone intercepting traffic to that IP (but not the client’s DNS path) couldn’t tell what site each connection was to. It mostly makes sense for CDNs, where the same IP will be used for many sites.

If you don’t use a CDN at all, the destination IP leaks what site you’re trying to connect to (if the domain is well known). If you use a CDN without ECH, you send an unencrypted domain name in the HTTPS negotiation so it’s visible there. ECH+CDN is an attempt to have the best of both worlds: your traffic to the site will not advertise what site you’re connecting to, but the IP can still be shared between a variety of sites.

It’ll be interesting to see how countries with lighter censorship schemes adapt - China etc. of course will just block the connection.

  • Even for China so-called "overblocking" where to censor a small thing you have to block a much larger thing, is a real concern with these technologies. There's a real trade here, you have to expend effort and destroy potential and in some cases the reward isn't worth it. You can interpret ECH as an effort to move the ratio, maybe China was willing to spend $5000 and annoy a thousand people to block a cartoon site criticising their internal policies, but is it willing to sped $50 000 and annoy a ten thousand people? How about half a million and 100K people ?

    • That requires the client to only emit ECH, even if the ISP-provided (and therefore government controlled) DNS blocks HTTPS/SVCB records. China can easily make the default for a browser in China be to never even try to use ECH as well. Then they'll only annoy people trying to actively circumvent their system. They already do TCP sessionization to extract the SNI domain. Detecting ECH and then just dropping the connection at L3 is functionally equivalent.

      In theory, sites could eventually require ECH to serve anything at all. But we're very far from that.

      6 replies →

This is so you do not leak the host through TLS. Using DNS to serve an encryption key.

It’s not just encrypted server name indication (ESNI), it is the whole hello now (ECH)! So you don’t leak anything.

My read is you still leak the host with DNS. This only prevents leaking the host with SNI. A useful piece but not at all the holy grail.