3 ms·

If it depends on DNS, does that not expose the name being requested via DNS and defeat the point of ESNI? I guess I need to go read up on this. Reading Cloud

If it depends on DNS, does that not expose the name being requested via DNS and defeat the point of ESNI? I guess I need to go read up on this. Reading Cloudflares blog, it appears they assume people are using DoH or DoT.

Fnoord 6y ago
Not if your DNS is encrypted (e.g. DNSCrypt, DoH, DoT, ...) I suppose it does if you run your own resolver?
- kevincox 6y ago
  But your resolver still needs to fetch those from somewhere. So you need encryption somewhere in the chain.
  - admax88q 6y ago
    DoH or DoT is encrypted. The address of the upstream resolver typically is hard coded or comes as a parameter during DHCP.
- pas 6y ago
  Plus both Firefox and Chrome has built-in DoH support.
ameshkov 6y ago
> it appears they assume people are using DoH or DoT Things changed since then, now plain DNS is also allowed.
w3ll_w3ll_w3ll 6y ago
If the DNS query is done with DoT or DoH the server name is not exposed.
- LinuxBender 6y ago
  That is what I took from their blog as well. For some reason I thought the original intent of ESNI was to do some type of opportunistic or self signed handshake for the (E)SNI portion to hide the requested name, then validate the actual site certificate. They must have run into a problem.
  - ameshkov 6y ago
    I've been loosely following ESNI/ECH drafts, and I am not sure this approach (double handshake) was ever seriously considered despite that it sounds perfectly fine to me. It'd make the handshake heavier, but on the other hand, it'd also make it much harder to distinguish from the regular TLS traffic. On the contrary, ESNI/ECH seems to be easy to detect and block, and some countries (China, for instance) have already announced that they're going to do that.
    - parliament32 6y ago
      There was nothing stopping a MITM with a fake/self-signed pre-handshake.
    - tialaramex 6y ago
      ECH is intended to be GREASEd which means there isn't an easy way to say "Block ECH only when it is used" because the obvious markers are present in every single connection. That is, an ECH implementing browser talking to some web site that doesn't do ECH will present it an ECH blob which is random gibberish. The web site doesn't do ECH, so it ignores the ECH, but a middlebox doesn't know that and if it wants to "block ECH" it must tear down this connection. If the same browser connects to a site which does have ECH the ECH blob isn't gibberish it's encrypted, the site decrypts it and treats the result as the real ClientHello. Historically China's Great Firewall is willing to put work in to detect and sabotage things it doesn't like. But the point of GREASing extensions is to ensure that the extension itself isn't poisoned. As a result most likely ECH will work fine in China, they'll just block IPs they don't like, punish citizens (or indeed visitors) they don't like, and that's an internal matter that the Chinese can take up with their government in the usual (and costly) way. This is not a magic anti-censorship tool, and isn't designed to be one. Even Tor isn't that, although its developers can point you at services that help if that's what you need.
deleted 6y ago
[deleted]
shawnz 6y ago
Since you need DNS to get the IP address in the first place, it's already true that ESNI is nearly useless without encrypted DNS.
- LinuxBender 6y ago
  True. I guess I assumed incorrectly that the original design of ESNI would not require DNS be in the flow for the validation, meaning that if I had local DNS, or /etc/hosts entries, then nobody would see the name. But if special record types are required, then /etc/hosts or local DNS won't suffice. Just my opinion, but it feels like this was made unnecessarily complicated. Feels like some concepts from SSH (host keys, caching host keys) and web servers (default _server_ name) could have been used for this, since I don't really need to validate who I am talking to for passing the name.
  - shawnz 6y ago
    Hopefully, browsers and operating systems will add capacities to store the records locally. They allude that this could be possible in the spec. > This document defines the format of the ECH encryption public key and metadata, referred to as an ECH configuration, and delegates DNS publication details to [HTTPS-RR], though other delivery mechanisms are possible.
  - londons_explore 6y ago
    > since I don't really need to validate who I am talking to for passing the name. If you don't validate who you're talking to, some ISP will run a MITM attack simply to log accessed hostnames (even if they can't MITM the final TLS connection)
    - LinuxBender 6y ago
      True, but this would be pretty easy to spot. I am ok with the compromise of using the same method used with ssh host keys for passing the name. The browser can cache these keys and tell the person if things are changing. At least that would be much simpler than these additional DNS lookups and assuming people are using encrypted DNS to a trusted DNS provider, but that is a whole other discussion.

Fnoord 6y ago

Not if your DNS is encrypted (e.g. DNSCrypt, DoH, DoT, ...) I suppose it does if you run your own resolver?

kevincox 6y ago
But your resolver still needs to fetch those from somewhere. So you need encryption somewhere in the chain.
- admax88q 6y ago
  DoH or DoT is encrypted. The address of the upstream resolver typically is hard coded or comes as a parameter during DHCP.
pas 6y ago
Plus both Firefox and Chrome has built-in DoH support.

ameshkov 6y ago

> it appears they assume people are using DoH or DoT Things changed since then, now plain DNS is also allowed.

w3ll_w3ll_w3ll 6y ago

If the DNS query is done with DoT or DoH the server name is not exposed.

LinuxBender 6y ago
That is what I took from their blog as well. For some reason I thought the original intent of ESNI was to do some type of opportunistic or self signed handshake for the (E)SNI portion to hide the requested name, then validate the actual site certificate. They must have run into a problem.
- ameshkov 6y ago
  I've been loosely following ESNI/ECH drafts, and I am not sure this approach (double handshake) was ever seriously considered despite that it sounds perfectly fine to me. It'd make the handshake heavier, but on the other hand, it'd also make it much harder to distinguish from the regular TLS traffic. On the contrary, ESNI/ECH seems to be easy to detect and block, and some countries (China, for instance) have already announced that they're going to do that.
  - parliament32 6y ago
    There was nothing stopping a MITM with a fake/self-signed pre-handshake.
  - tialaramex 6y ago
    ECH is intended to be GREASEd which means there isn't an easy way to say "Block ECH only when it is used" because the obvious markers are present in every single connection. That is, an ECH implementing browser talking to some web site that doesn't do ECH will present it an ECH blob which is random gibberish. The web site doesn't do ECH, so it ignores the ECH, but a middlebox doesn't know that and if it wants to "block ECH" it must tear down this connection. If the same browser connects to a site which does have ECH the ECH blob isn't gibberish it's encrypted, the site decrypts it and treats the result as the real ClientHello. Historically China's Great Firewall is willing to put work in to detect and sabotage things it doesn't like. But the point of GREASing extensions is to ensure that the extension itself isn't poisoned. As a result most likely ECH will work fine in China, they'll just block IPs they don't like, punish citizens (or indeed visitors) they don't like, and that's an internal matter that the Chinese can take up with their government in the usual (and costly) way. This is not a magic anti-censorship tool, and isn't designed to be one. Even Tor isn't that, although its developers can point you at services that help if that's what you need.

deleted 6y ago

[deleted]

shawnz 6y ago

Since you need DNS to get the IP address in the first place, it's already true that ESNI is nearly useless without encrypted DNS.

LinuxBender 6y ago
True. I guess I assumed incorrectly that the original design of ESNI would not require DNS be in the flow for the validation, meaning that if I had local DNS, or /etc/hosts entries, then nobody would see the name. But if special record types are required, then /etc/hosts or local DNS won't suffice. Just my opinion, but it feels like this was made unnecessarily complicated. Feels like some concepts from SSH (host keys, caching host keys) and web servers (default _server_ name) could have been used for this, since I don't really need to validate who I am talking to for passing the name.
- shawnz 6y ago
  Hopefully, browsers and operating systems will add capacities to store the records locally. They allude that this could be possible in the spec. > This document defines the format of the ECH encryption public key and metadata, referred to as an ECH configuration, and delegates DNS publication details to [HTTPS-RR], though other delivery mechanisms are possible.
- londons_explore 6y ago
  > since I don't really need to validate who I am talking to for passing the name. If you don't validate who you're talking to, some ISP will run a MITM attack simply to log accessed hostnames (even if they can't MITM the final TLS connection)
  - LinuxBender 6y ago
    True, but this would be pretty easy to spot. I am ok with the compromise of using the same method used with ssh host keys for passing the name. The browser can cache these keys and tell the person if things are changing. At least that would be much simpler than these additional DNS lookups and assuming people are using encrypted DNS to a trusted DNS provider, but that is a whole other discussion.