341–350 of 367 posts
Earlier quoted context omitted.
You can also DNAT all port 53 traffic to your resolver. Devices will think they are talking to 8.8.8.8 or whatever, but in reality they will ask your resolver and your filtering will apply. Your filtering can still break these devices.
This only works as long as DNS is both unauthenticated and unencrypted.
Obviously, it would work with DoT (853) only with cert verification disabled.
Earlier quoted context omitted.
Complain to who exactly? > 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…
> 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 i…
Be careful what you wish for
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.
Earlier quoted context omitted.
> DoH is highlighting the security nightmare that is AWS, GCP, Azure, Cloudflare etc with their reverse proxies and virtual hosts, making it impossible to safely restrict a network from communicating with only a specific cloud-hosted service. This problem goes back a lot further than that — even prior to having CDNs in common usage you had plenty of different clients sharing IP space at hosting companies and the real…
> Trying to hijack DNS is only useful when you control the network but neither the client or server. This is a very common scenario in retail and SME businesses where you can’t control the on site hardware, eg fuel pumps or CCTV or cash registers or footfall counters or vending machines or whatever, and you can’t control what IPs they talk to. But you still have an obligation to minimise their network access. Unfortu…
Earlier quoted context omitted.
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.
Not really if that hoster is Cloudflare.
Earlier quoted context omitted.
Blocking traffic for known DoH services would be trivial. How about blocking unknown, how would you block that?
Think out of the box: Just don't let the app connect to an IP it has not resolved a domain name for. That's what we can do with the Portmaster ( https://github.com/safing/portmaster ). Check it out!
Earlier quoted context omitted.
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 everythi…
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 pac…
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.
Earlier quoted context omitted.
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. Surel…
"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: https://github.com/kontaxis/snidump ESNI-enabled softwa…
Earlier quoted context omitted.
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 pac…
> 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…
Earlier quoted context omitted.
> 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…
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.
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.)
Earlier quoted context omitted.
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…
This isn't new to DoH. Malware has used alternatives to DNS for getting command & control server IPs for decades. IRC used to be common, for example.