DoH absolutely can get network filtering: if I block port 53 outbound to control DNS queries within my network, DoH (and other tunneling technologies) is bypassing my network filtering of DNS.
The solution is to start doing network filtering: if you block packets to unapproved servers, you can actually stop this. You’ll need to run your own proxy, of course, but that’s always been the only way to actually accomplish that goal.
This is a very good point and I am dealing with this myself on my home networks.
Like any household/family we have some number of dubious/untrusted devices that still need Internet access.
By establishing my own recursive resolver I can act as a chokepoint (and monitoring point) for their behavior online. It's a very elegant solution, actually, and I have created a nice integration between my datacenter-hosted resolver and nextdns.io as the adblocking upstream DNS.
DoH breaks all of this.
I have no interest in diving down the "MITM my own network by inserting custom certs into embedded devices that may or may not use them".
Since we're talking about it, though, it occurs to me that you could quickly do a DoH lookup to every single new IP connected to, outbound, from your network - and then block all IPs that answer your DoH query. You're basically pre-testing all new SSL connections to see if they are to a DoH resolver that you (presumably) don't want to talk to ...
This solves the CDN problem ... does it solve the problem entirely ? I have only just thought of this moments ago ...
This only works for the subset of devices which use the local DNS. If they use any of the well-known techniques to avoid that filtering it's completely ineffective.
> Since we're talking about it, though, it occurs to me that you could quickly do a DoH lookup to every single new IP that initiates a new connection, outbound, from your network - and then block all IPs that answer your DoH query.
It doesn't solve the CDN problem: CDNs will route traffic based on the hostname and blocking them will have a degree of collateral damage which most people can't work with. Setting up your own HTTPS proxy avoids this.
If you also block all port 53 after allowing your own resolver ... you may have some headaches with devices that refuse to use the DHCP provided resolvers but you know they aren't going to other resolvers.
That kind of control is what DoH breaks and I'd love to find an elegant (non-MITM proxy) solution for it ...
And in the context of pihole and such, avoiding that means editing the DNS response to remove those public keys. Which takes us full circle back to "do I control DNS for this gadget, or not".
Of course, jailbreaking opens up other security issues, so it goes back to what you can tolerate.
[0] https://checkrain.org/ [1] https://letsencrypt.org/getting-started/
I would imagine you can use this to push any certificate that you can also push to an iOS/iPadOS/macOS device.
I would also love to MitM myself in some cases, mostly because it’d be interesting to see what’s going on.
So before applying that mentality, it would be wise to consider what your experience would be like if all your neighbours, friends, colleagues etc also did that on their networks.
For this reason I wouldn't recommend buying a device like the Chromecast, in which the user can't configure the network settings. Instead maybe consider something like the Amazon Fire Stick which is not as user-hostile.
The usual approach to setting up a firewall is a default of "block everything" and then selectively allow only what is needed.
Most people cheat and only do this on inbound connections, allowing everything on the egress side, because it's easier. But if you want to block your IoT devices from making outbound https connections, you easily can.
There's nothing really new going on here. It's always been possible to tunnel one protocol over another, or use nonstandard ports, and use encryption on the traffic to hide what you're doing.
The point of the original story is "your" meaning a device you own, is ignoring your network controls
it is highly unlikely that the TV manufacturer is going to allow me to install my own custom root certs to inspect their traffic to HTTPS, so yes DoH and other things are a threat to network security, because if the TV become compromised I have limited administrative controls to prevent it other the blocking it completely which is a poor response to the problem
DoH is a solution in search of a problem that can be solves in better more user friendly ways
Standard DNS is unencrypted. DNS-over-HTTP is encrypted. Or DNSSEC or any number of newer standards that secure the DNS lookup. At that point, filtering will require MITM proxies, whether it's for DNS or HTTP or any other protocol.
It's a trade-off with security on the open network meaning harder penetration and control in your internal network. There's no easy answer.
Why do you say it's not authenticated? If they're using the newer standards then that's what it provides. If they're not then there's no issue with network filtering as usual.
It doesn't matter if you're using your ISP's servers, 8.8.8.8, 1.1.1.1, or a custom server you set up on Digital Ocean somewhere: an on-path attacker can forge DNSSEC responses to you. It's a ridiculous situation.