As someone who recently set up a pihole, I was shocked that it was possible to redirect all DNS requests on the network (in plain text!) to the pi. I did the method where you set up a network firewall at the router level that redirects all port 53 traffic to the pi. It's a nice feature for getting my xbox filtered, but it really felt like an insecure historical quirk rather than a feature we should be praising.
Surely it's progress for devices to be able to securely access name servers? I can't snoop on the network traffic going over https but somehow I can get a list of all names queried?
If I get access to those devices, yeah, sure. But in practice, I'd argue this actually reduces privacy for users, as it gives apps and devices a secure path through the network which cannot be monitored by any intermediary - including the user of the app or the owner of the device themselves. So no chance to find out what kind of data is being transmitted there either.
To me, DoH seems less about protecting the user from attackers and more about protecting apps and devices from the user.
I think your point is 100% correct but surely you understand that this applies to HTTPS too. Network filtering would be so much more powerful if my pihole could modify and block HTTP requests in-flight.
One way to limit this would be to add IP resolved through an approved resolver to a temporarily allowlist for a firewall. The firewall would default-deny outbound network requests. Allowlisted IP would be permitted, but be removed from the list after the TTL for the DNS request expires.
Of course, you'd have to add in some permanent exceptions once you realize just how much hardware and software implodes as a result of this.
Some expected, like peer-to-peer applications, though those allow you to define an outbound ephemeral port range you can limit them to (except perhaps for some poor implementations in commercial game launchers trying to offload bandwidth costs). So some are fairly easy to define.
Others you'll have to log and see. Like your Google Home hardware..
I got some minis and disabled the mics since they had hardware switches. I hacked around a bit emulate sending them audio programmatically and discovered they use external DNS and therefore couldn't resolve the local network web server hosting the audio clips I wanted to play. So I had to permanent-lease the hostname's IP and give it an IP address.. They were already bypassing local DNS blockers years ago.
> add IP resolved through an approved resolver to a temporarily allowlist for a firewall
That ship has sailed now that some of the functionality provided by TCP moved up to HTTPS. Whereas in the past you could expect the same IP to expose DNS on port 53, FTP on port 21, or HTTP on port 80, now the same IP will serve you everything over the handy port 443.
So a software developer can very well go this route if they want to obfuscate DNS calls and you wouldn't be able to discriminate the traffic like you would today with ports.
Any global (OS/network) policies become meaningless if your browser or app decide to only ask the DoH resolver "who is google.com" or "who is facebook.com" once, and have all subsequent queries go that way inside an encrypted HTTPS stream.
Key word is any single intermediary. The announcement even explicitly says "no single entity can see both at the same time".
I wonder what it would be like if there were multiple entities in cooperation, each sharing their component of your request with their partners to recover the entirety. You could cover the entire planet with access to even as few as three or five or so large networks.
You're definitely right that it is an issue that the traffic is plaintext but there are trade off costs that are not addressed by these standards, mostly in user control and fall back behaviour.
You've started using a pi-hole, and presumably are getting value from it. These protocols can potentially make it so you can't use that pi-hole at all.
Traffic that is local to a network being unencrypted is not a huge privacy problem. If this protocol was adopted by local resolvers, your pi-hole or network router could use it for any requests it makes while still preserving its ability to filter the traffic. It's basically all win under this scenario.
The problem comes back to applications implementing this in ways that can't be managed taking the option away from end users and administrators. Without the protocols specifying control and fall-back behaviours on networks that don't need or want this, it's more harmful than useful.
Can you explain (or share a link) to some proposal for how to enable my pihole to securely talk to upstream resolvers but force all embedded devices on my network to go through the pihole? Anything that lets my pihole sidestep my ISP seems like it'd also work for my xbox.
> force all embedded devices on my network to go through the pihole
You can only do this for the devices that respect your DHCP-provided DNS config. Even if you redirect all port 53 traffic on your network to your pihole, a device can make its own (DoH or non-DoH) https connection and gets DNS responses via that, bypassing your pi-hole.
This was discussed extensively a few days ago on a thread about "72% of smart TVs and 46% of game consoles hardcode DNS settings":
If you control DHCP and know the MAC address of those embedded devices, you can serve them a non-existing gateway so that they simply won't have a path outside of your home network.
Of course, that assumes IPv4, whereas with IPv6 and SLAAC I believe the only way is to firewall them out.
You essentially run a little proxy server on your pihole setup, and configure pihole to use it as your upstream dns resolver.
E.g., a proxy server running at 127.0.0.1:5053 which uses the Cloudflare ipv4/ipv6 DNS over HTTPS endpoints. This can also use other DoH endpoints as desired:
It’s being worked on again. The “client side” (from client to resolver) got all the attention in recent years. Even though it’s arguably less important than encrypting resolver to Auth traffic (as the resolver can often be close.).
Cynics say this is because there was money behind DoH which pushed it through standardisation, as the big providers are hungry for the data.
I have used CurveDNS forwarders at home as an experiment for many years now. I have never had any problems. I cannot see why authoritative DNS providers would resist offering DNSCurve as an option. It is relatively easy to set up and does not require replacing or modifying any DNS software.
I don't have any resources handily available for that. I would be truly surprised if pi-hole's don't support DoH though so I'd just try searching for something like "enabling DoH on a pihole" or similar.
Basically sounds like you've already done the hardest parts. Your router is redirecting all DNS traffic to your pi-hole, this will prevent any normal unencrypted DNS traffic from leaving your local network. You pi-hole will be in turn making all the DNS requests. If you turn on DoH for the pi-hole all the DNS requests on your network will be encrypted.
"I can't snoop on the network traffic going over https but somehow I can get a list of all names queried."
SSL/TLS's servername extension puts those names in plaintext just like DNS. The popular browsers all include this extension even when the website does not require it.
As such, one can get a list of names by snooping on HTTPS traffic, instead of DNS traffic:
It’s progress if you control your devices, or you don’t control your network.
I don’t. Like most people I can control my network.
I have all sorts of crap on my network from Bose and amazon and Nintendo and Apple etc on my IoT vlan.
Without going to a monk style digital life aka RMS, the best bet is to segment them into a secure network and limit what they can communicate with. The DOH Culture and the like takes away my freedoms.
Then complain about devices that hardcode settings and don't allow changing them, rather than complaining about people taking what devices could already do and standardizing it so that anyone can use it in a more uniform way.
> people taking what devices could already do and standardizing it so that anyone can use it in a more uniform way.
In this case, standardization makes a huge difference.
Before DoH, this was theoretically possible, but needed enormous effort to pull off: The simplest thing a device could do was to hardcode custom DNS servers - but the network admin could easily bypass that by redirecting the packets, as described in this subthread.
Any more interception-proof solutions would have involved designing a custom network protocol, running a custom server and implementing custom bootstrapping logic to connect the device to the server - and even then, the traffic would stand out enough than an admin could still block or redirect it easily enough.
With DoH, there are publicly accessible servers that accept requests over plain HTTPS: This means, someone who wants to keep their ads from being blocked does not need to run any server infrastructure and does not need to fiddle with network code at all - they can just drop in a DoH client library, hardcode a list of public DoH servers and client certs and be done. This is absolutely a game-changer.
> With DoH, there are publicly accessible servers that accept requests over plain HTTPS
Which is a good thing for end users on balance.
The Internet is going 100% encrypted and that's a good thing. This helps towards that goal. Relying on unencrypted traffic will no longer work. Networks must not have the ability to intercept device traffic unless the device administrator (not the network administrator) configures it as such; any such mechanism completely breaks the security properties this is trying to achieve. Ultimately, your choice with uncooperative devices is "block the device or don't" (in addition to isolating it on a separate network), along with "replace it with a cooperative device". Stop telling people they need to stop using encryption so that your local network interception will keep working, because your local network interception is indistinguishable from other people's local network interception.
This feels like the geek version of DRM fallacies or the fallacies that governments believe about encryption. Somehow, there continue to be threads full of arguments that amount to "It should be possible for 'good' network admins to intercept traffic from devices that don't trust them, but 'bad' network admins shouldn't be able to intercept traffic from devices that don't trust them". That's fundamentally not possible; any mechanism usable by 'good' network admins can be used by 'bad' network admins. (Leaving aside that 'good' and 'bad' are relative.) And worse, people get so invested in their local network interception that once it becomes clear that isn't possible, some will start arguing that their local network interception is more important than general Internet security.
There are enough outside opponents of Internet security; let's not start holding back security ourselves because it makes our own hacks stop working. We have enough work to do fighting for the ability to keep the Internet secure against real adversaries. We absolutely need full control over our own devices, but many of the people most capable of fighting for that control got complacent about it because a subset of people could hack around it with local network interception stunts.
> there continue to be threads full of arguments that amount to "It should be possible for 'good' network admins to intercept traffic from devices that don't trust them, but 'bad' network admins shouldn't be able to intercept traffic from devices that don't trust them"
That's not what I see at all.
I see people pointing out that DoH hurts privacy and reduces control for end users by providing a convenient turnkey solution for device vendors to bypass filtering at the network level.
I also see it pointed out that DoH could have been specified in a way that facilitated filtering for the local network. Given that it's so obviously possible, the fact that it wasn't speaks volumes.
Note that (IIUC) your ISP can still see which sites you visit because TLS still transmits the FQDN in plaintext (https://security.stackexchange.com/questions/86723). Even if that stopped happening tomorrow, the destination IP would still be visible (not quite as bad but still reveals a huge amount of information). On top of all that, DNSSEC already exists which allows you to verify the authenticity of the query result. As such, the argument in favor of DoH would seem to be limited to preventing your DNS resolver (but not your ISP or VPN!) from tracking which sites you visit. I don't find that to be very compelling in light of the immediate downsides.
> I also see it pointed out that DoH could have been specified in a way that facilitated filtering for the local network. Given that it's so obviously possible
No, it couldn't have been, and this is exactly what I was referring to in my comment. Any mechanism that allows the local network to intercept the traffic of a device that doesn't trust the network can and will be abused. The entire point of DoH was to make DNS clients secure, by preventing ISPs and other network providers from monitoring, intercepting, or tampering with DNS results.
You're asking for DNS to be left insecure, so that you can tamper with it. You're asking for the security of clients that actually give users control (laptops, phones, etc) to be sacrificed so that you can continue to tamper with DNS results for clients that don't give users control.
> On top of all that, DNSSEC already exists which allows you to verify the authenticity of the query result.
DNSSEC isn't nearly widespread enough to expect to find it everywhere. Only very specialized clients could make it a requirement; most clients cannot. DNSSEC requires upgrading most of the world before people can rely on it; DoH is an incremental solution.
> As such, the argument in favor of DoH would seem to be limited to preventing your DNS resolver (but not your ISP or VPN!) from tracking which sites you visit.
SNI is being fixed. Once SNI is fixed, DNS is one of the last holes that allows your ISP or other network provider to track you.
And as mentioned above, since DNSSEC is not a viable solution anytime soon, DoH is also critically important to prevent ISPs and other network providers to tamper with your DNS results.
Some color to this: it's less than 2% of North American domains, the number of signed zones has actually dropped in some intervals, and it's practically nonexistent among big companies with security teams. Google isn't DNSSEC-signed. Neither is Microsoft. Or Facebook. Or Amazon (whose DNS service, Route53, doesn't implement DNSSEC). Or, last I checked, any US bank.
You can check this for yourself: make a list of domains, and then write a trivial script:
#!/bin/sh
while read domain
do
ds=$(dig ds $domain +short)
echo "$domain $ds"
done
What I think will end up happening, most of the devices will go encrypted route [1]. Most things will run over https, and with encrypted sni, you won't even be able to block domains.
Encryption will be backdoored by governments (and of course other people that will reverse those backdoors or have friends in LEA ).
End result is encryption that people are championing as improving our privacy will make us more exposed and more vulnerable, because other people will have more access to our network, devices and data than we do.
I can and do run linux, so I don't have to worry about my os. But my hardware might phone home on its own. Phones are already lost causes. TV's almost as well.
I do hope you are right and I am wrong, I'd much rater be wrong.
[1] You already have hard time buying non smart TV. A lot of things nowadays expect network connection, and that trend is increasing.
People advocating a 100% encrypted Internet are also many of the same people fighting tooth and nail against backdoored or otherwise broken encryption.
It doesn't make sense to say that encryption will be backdoored so we should use plaintext. We should fight for security across the board, and fight against any threat to that security.
> This feels like the geek version of DRM fallacies or the fallacies that governments believe about encryption. Somehow, there continue to be threads full of arguments that amount to "It should be possible for 'good' network admins to intercept traffic from devices that don't trust them, but 'bad' network admins shouldn't be able to intercept traffic from devices that don't trust them". That's fundamentally not possible; any mechanism usable by 'good' network admins can be used by 'bad' network admins. (Leaving aside that 'good' and 'bad' are relative.) And worse, people get so invested in their local network interception that once it becomes clear that isn't possible, some will start arguing that their local network interception is more important than general Internet security.
That's not the distinction at all.
It's that you should be able to set up interception on the local network at install time, but all other interception should be blocked. It's extremely possible.
I’m not held hostage by my ISP - I choose one that doesn’t do that. Even if I didn’t trust the last mile, that’s why I can choose to implement a vpn for some or all of my devices on my network so I can bypass a hostile isp.
It might be good for the average technophobic end user to trust google instead of their ISP, but it’s not good for me to trust google over my ISP.
Most users do not have a meaningful choice of ISPs. That was true back in the days of modems, and somewhat true in the days of DSL. It is not true at all in the days of fiber and cable.
> Networks must not have the ability to intercept device traffic unless the device administrator (not the network administrator) configures it as such
The device admin of an iPhone is Apple, the device admin of a non-rooted Android phone is Google, the device admin of a Windows 10 PC is Microsoft and the device admin of a smart TV is likely Samsung. Is that the point you want to make?
All of those companies have incentives to collect user data and are known to push user-hostile changes. They also either have known ties with the NSA or can be coerced via National Security Letters, making even the tired point about "defense against state actors" moot. Do you trust any of them?
If, say, Tencent brought a phone to market in the US that turns out wildly popular but happened to exchange vast amounts of data with servers in China, would you be ok with that?
Most devices today have locked-doen bootloaders, so I don't actually have a choice about the device admin for my device. The position of network admin can be abused, too, but at least there is a possibility I can fill this position myself or can delegate it to someone who I trust.
> Ultimately, your choice with uncooperative devices is "block the device or don't", along with "replace it with a cooperative device".
Right now there are huge market incentives to make devices ever more uncooperative. Unless something changes, the choice for consumers will likely be soon "tolerate an uncooperative device and don't block it - or opt out of technological progress altogether".
> That's fundamentally not possible; any mechanism usable by 'good' network admins can be used by 'bad' network admins.
This argument doesn't get any more coherent no matter how often it's repeated. Somehow the tech industry keeps arguing that the key to any kind of mandatory backdoor will leak with mathematical certainty - while employing that exact same kind of backdoor for their own purposes without any worry - in the form of forced updates and forced telemetry. How exactly can the same technology be a security risk when used by a government but a security best practice when used by a private company?
> We absolutely need full control over our own devices, but many of the people most capable of fighting for that control got complacent about it because a subset of people could hack around it with local network interception stunts.
So then what would be your idea how to gain control?
Yes. Which is why it's no longer as popular. The point is that malicious actors have never followed the system's preferences on how to look up server IPs, so why the hell should they start now? DNS blocking hasn't worked up to now, why complain that it's suddenly broken?
The 'historical quirk' per my understanding is pretty much IPv4 NAT.
At least, I couldn't figure out how to do it with IPv6 (no (need for) NAT) - I ended up dropping them if not destined for my desired DNS instead.
(NAT lets you Translate Addresses, usually to save IPv4 space, but here to redirect to a different DNS. IPv6 fixes the address space problem with more addresses, so the hack is done away with, and everything on the network can 'route itself' to everything else without any translation, as pre-NAT and as always intended.)
Transparent proxying works for IPv6 as well as IPv4. It's a little challenging to do transparent proxying on a box that's not the firewall. If the firewall and the proxy are on the same ethernet broadcast domain, you can forward the packets (i think for Linux you'd need to do policy routing on the port?, for ipfw there's a forward action, i think pf would be route-to); and if they're not, you'd need to tunnel the packets to the proxy.
NAT doesn't really have much to do with it, other than you with NAT, you certainly have a device on your network that's capable of being a transparent proxy, whereas without NAT, you could just have a unmanaged switch to share your upstream connection between multiple computers; assuming your provider is enlightened and provides ethernet or an ethernet bridge with nothing else in the way.
> think for Linux you'd need to do policy routing on the port?
I think that's probably the crux of what I'm getting at - and I should say this is all from fiddling at home and not working in networking - with iptables you can `-j DNAT --destination $desired_dns_ip`, but if you don't have NAT then you're left with `-j REDIRECT --dport $portchange`, which yes, takes a destination port, not IP.
> other than you with NAT, you certainly have a device on your network that's capable of being a transparent proxy
Yes exactly, that's all I meant really. After all, the context is a home user configuring a home user's 'router' (i.e. switch, firewall, AP, ...) to send DNS requests to PiHole, right.
The first part is really just a tooling issue. iptables doesn't have a -j FORWARD to pass the packet as-is to another host, but it's certainly possible to make it happen. I didn't look at nftables to see if it does either.
Yeah absolutely, as I said in a another branch of this thread, it's all just (plaintext even) 1s & 0s at the end of the day, you can flip some; I do understand that.
It's just that our starting point here was something like 'what can a software engineer do in an hour or so one evening to get their home DNS traffic going through a Raspberry Pi on the LAN'.
I happened to have, er, exactly this experience recently with my (OpenWRT) router(+...) and with that tooling, I couldn't make it work. I settled for DNAT for v4 & DROP^ for v6 because that's what I could get done that evening and it didn't (and hasn't) seem(ed) to be a problem.
^(as in, anything trying to use a different IP, if it's already destined for my DNS that's fine. The hope being that it falls back on v4 at least, even if not the provided DNS over v6.)
Of course it's technically possible, it's all just packets of data that you can change, at the end of the day. I just meant that the easy way to do it (AIUI) went away with IPv6 because you were never supposed to need to do that, and with v6 you 'don't'.
It's not like the purpose of firewalls is redirection.
I thought that iptables was the easy way to do it? (Both for IPv4 and IPv6.)
NAT66 is an experimental (10 years old IIUC!) RFC for one-to-one IPv6 mapping. While there's no RFC specifying an official method of masquerading behind a single address, AFAIK iptables "just works" (as long as you aren't running FreeBSD).
Yeah it is true, but the problem is if DoH with its privacy features come along it will be literally impossible to block ads with PiHole, as all DNS quesries will be encrypted (which DoH does ofc rihgt now).
So no ability to block ads in TV or malicious domains that IoT deviced connect to or even blocking Windows, macOS telemetry network wide as all DNS requests will be encrypted which they are not as of right now.
It will be possible, just harder. I will not be surprised if there will be services where one can get a database of IP addresses of bad domains and one could block that, the same way one does with spammers. Surely it may block sites that share hosting on those domains, but it then it puts pressure on sites to avoid such sharing sharing.
Surely it's progress for devices to be able to securely access name servers? I can't snoop on the network traffic going over https but somehow I can get a list of all names queried?