[assassinator42]

This is going to make it even more of a pain to do egress filtering on networks/systems we administer. I want to be able to allow list sites with dynamic IPs. The existing solutions for doing this by examining SNI are already often bypassable by forging the SNI (looking at you, AWS Network Firewall).

[LinuxBender]

CF explain how to do this here [1]. Have your local DNS resolvers filter the HTTPS type of DNS queries on your DNS servers. One example from Microsoft [2]. Unbound would probably need a patch though a work-around could be an iptables string filter or u32 filter for the record type. There is a DNS module [3] for iptables but it is not part of any default installations AFAIK.

The second way is to return a “no error no answer” or an NXDOMAIN response to queries made to the use-application-dns.net.

I personally already use the second option to block DoH and cell phones seem to automatically figure out to use port 853 for DNS-Over-TLS on my home router Unbound DNS. I also null route most of the public DoH servers. People point out that DoH can be on any CDN IP but it never has been.

[1] - https://developers.cloudflare.com/ssl/edge-certificates/ech/

[2] - https://learn.microsoft.com/en-us/windows-server/networking/...

[3] - https://github.com/mimuret/iptables-ext-dns

[bscphil]

This only works because browser vendors have taken the totally bullshit approach of "you're only allowed to use ECH if you have DoH enabled", even though they're really unrelated technologies. Related Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1500289

Of course this kind of filtering is useless to stop a determined user (in a bring-your-own-device environment) because they can trivially just run their own DoH endpoint.

[josephcsible]

> The second way is to return a “no error no answer” or an NXDOMAIN response to queries made to the use-application-dns.net.

This misfeature can't be removed from browsers soon enough. Its existence is totally contrary to DoH's threat model, since the people DoH is designed to protect you from are exactly the ones who can manipulate insecure DNS results for that domain.

[growse]

It's just a network hint. Browsers are free to ignore (and I think Firefox has a toggle to ignore it).

[LinuxBender]

and I think Firefox has a toggle to ignore it

They do. It used to be one had to modify modes in about:config but now there is a GUI for it in the settings.

[1] - https://support.mozilla.org/en-US/kb/dns-over-https

[LinuxBender]

That DNS module for IPTables actually looks to be a bit outdated and is missing the type HTTPS as far as I can tell so maybe a request to the people at nlnetlabs to add options for query types to block in Unbound DNS may be useful.

[josephcsible]

You're supposed to do that kind of filtering on the endpoint. If it's possible anywhere else, then it could be used to censor other people's computers.

[folmar]

I'm afraid you only take into account private use.

On-endpoint filtering is not enough on a large scale. In a network with expected high level of security I don't trust the endpoint and censoring them is a feature, there is no moral or legal expectation of privacy, but data integrity would be nice.

[josephcsible]

If you own all of the endpoints, then it is indeed morally okay for you to do network-level filtering. The problem is that if we design network protocols so it's possible for you to do that, then it will also be possible for people to do network-level filtering that affects endpoints they don't own.

[jbombadil]

I see your point, but on my network I want that ability.

I want to have my tv connect to YouTube, but not phone Sony/Samsung/whoever.

I want to be able to setup a pihole to block adds independently of the browser/device being used.

[josephcsible]

How do you propose that it be possible for you to do that to things like your smart TV without it being possible for you to do that to other people's computers?

[new23d]

Sorry for the plug but DiscrimiNAT Firewall actively prevents ECH [1] from flowing through and cannot be bypassed with SNI forging either [2]. Also has a great 'discovery' mode and CLI tooling to figure out that allowlist on an on-going basis.

[1] https://chasersystems.com/blog/disabling-encrypted-clienthel... [2] https://chasersystems.com/discriminat/comparison/aws-network...

[jeroenhd]

If you're doing any SNI filtering, you can validate the SNI with the certificate passed in the ServerHello (which most tools skip, because that's computationally expensive in comparison). This involves reconstructing message streams as well, of course. You'll also need to figure out how to deal with 1RTT (probably block it).

I don't think it's much more of a pain than it already was. You can disable the feature on your side if you don't want it, and block+log any traffic with ECH enabled. Hell, you can set up an intercepting proxy with your own CA if you want. That way, nothing gets out without at least getting logged.

Of course this becomes quite difficult if you don't own the devices you're monitoring, but that is kind of the point behind TLS/ODoH/ECH.