5 ms·

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

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

josephcsible 3y ago
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 3y ago
  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 3y ago
    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 3y ago
  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 3y ago
    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?
LinuxBender 3y ago
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/ https://developers.cloudflare.com/ssl/edge-certificates/ech/ [2] - https://learn.microsoft.com/en-us/windows-server/networking/dns/deploy/apply-filters-on-dns-queries https://learn.microsoft.com/en-us/windows-server/networking/... [3] - https://github.com/mimuret/iptables-ext-dns https://github.com/mimuret/iptables-ext-dns
- bscphil 3y ago
  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 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 3y ago
  > 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 3y ago
    It's just a network hint. Browsers are free to ignore (and I think Firefox has a toggle to ignore it).
jeroenhd 3y ago
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.
new23d 3y ago
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-clienthello-in-google-chrome-and-why/ https://chasersystems.com/blog/disabling-encrypted-clienthel... [2] https://chasersystems.com/discriminat/comparison/aws-network-firewall/ https://chasersystems.com/discriminat/comparison/aws-network...

josephcsible 3y ago

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 3y ago
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 3y ago
  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 3y ago
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 3y ago
  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?

LinuxBender 3y ago

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/ https://developers.cloudflare.com/ssl/edge-certificates/ech/ [2] - https://learn.microsoft.com/en-us/windows-server/networking/dns/deploy/apply-filters-on-dns-queries https://learn.microsoft.com/en-us/windows-server/networking/... [3] - https://github.com/mimuret/iptables-ext-dns https://github.com/mimuret/iptables-ext-dns

bscphil 3y ago
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 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 3y ago
> 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 3y ago
  It's just a network hint. Browsers are free to ignore (and I think Firefox has a toggle to ignore it).

jeroenhd 3y ago

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.

new23d 3y ago

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-clienthello-in-google-chrome-and-why/ https://chasersystems.com/blog/disabling-encrypted-clienthel... [2] https://chasersystems.com/discriminat/comparison/aws-network-firewall/ https://chasersystems.com/discriminat/comparison/aws-network...