[deleted]
Improving DNS Privacy with Oblivious DoH
201–210 of 367 posts
Re: Improving DNS Privacy with Oblivious DoH
#202Earlier quoted context omitted.
If the network allows outbound traffic, they can hard-code an IP list - this is how Cloudflare’s 1.1.1.1 works and malware has done this for decades – or they can use local DNS to resolve a single name which will answer or redirect to a service which does further queries. Malware commonly used IRC for this until that started getting blocked on most networks, but imagine how easy it would be to miss, say, a bot which…
Yeah, it’s an arms race, but I suspect it’s solvable: at least solvable enough that it’s feasible to just not use devices that break your policies. For things like Pi-Hole, the setup I describe will reduce much of the ad noise even without more complicated systems.
The way to solve is either to segregate unmanaged devices onto a separate network and give up on controlling them or to implement the system I described. The same Pi running a DNS server can run a proxy which applies blocking policies on all hostnames.
Re: Improving DNS Privacy with Oblivious DoH
#203Earlier quoted context omitted.
It has nothing to do with DNSSEC.
Huh? They say this: > The whole process begins with clients that encrypt their query for the target using HPKE. Clients obtain the target’s public key via DNS, where it is bundled into a HTTPS resource record and protected by DNSSEC. When the TTL for this key expires, clients request a new copy of the key as needed (just as they would for an A/AAAA record when that record’s TTL expires). The usage of a target’s DNSSE…
Thank you for the part regarding DNSSEC--I was just about to post the same thing.
Re: Improving DNS Privacy with Oblivious DoH
#204This is a neat design, but, does this not just shift the issue of trust as to whether the proxy and the target are colluding: > However, each of these guarantees relies on one fundamental property — that the proxy and the target servers do not collude. So long as there is no collusion, an attacker succeeds only if both the proxy and target are compromised. I'm not sure how an end user would be expected to assess this…
Add a few more proxy hops and you’ve effectively reinvented Tor
.. but the version of Tor which does not raise alarms on every corporate firewall/IDS system
Re: Improving DNS Privacy with Oblivious DoH
#205The biggest and most consistent downside I see with these DNS enhancements is that it prevents filtering at the network level. Querying nameservers is being pushed into applications themselves to support these new features (such as Chrome and Firefox), which bypasses any system resolvers configured on the host. In most cases there is no way to signal from the network that it is not desirable to do this (Firefox being…
On every single operating system it is possible for this kind of improvement to be installed as a system-wide replacement for the local resolver, whether by a direct plugin or by running a resolver on localhost. This is how these upgrades can be deployed if you don't want to wait for the OS.
The problem is that browsers and other applications are just unwilling to let the user see how their products work or decide anything for themselves--or even just architect their installers to involve dependencies on a shared resolver upgrade--and so we end up in this hell of applications actively hiding their traffic from you.
And like, "great": now we have a new version of DoH and have to wait for everyone to upgrade their apps that upgraded to DoH before? This is ridiculous bullshit... this should be a single app on your device you now upgrade. Hell: Cloudflare even develops that app for a number of platforms! They aren't even the problem... it is everyone who jumps on "embedding" this behavior :/ :/ :/.
(For a more technically-comprehensive rant about this, read my comment from a year ago:)
Re: Improving DNS Privacy with Oblivious DoH
#206The biggest and most consistent downside I see with these DNS enhancements is that it prevents filtering at the network level. Querying nameservers is being pushed into applications themselves to support these new features (such as Chrome and Firefox), which bypasses any system resolvers configured on the host. In most cases there is no way to signal from the network that it is not desirable to do this (Firefox being…
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…
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.)
Re: Improving DNS Privacy with Oblivious DoH
#207Earlier quoted context omitted.
> DoH has at least Mozilla and Google on board, and presumably Microsoft are tailing along. Note that DoH (and DoT) shipped in iOS 14 and Big Sur, though aren't particularly easy to enable.
Note that DoH (and DoT) shipped in iOS 14 and Big Sur, though aren't particularly easy to enable. You can use something like iMazing Profile Editor [1] to create a .mobileprofile (which is just XML) to configure DoH or DoT. [1]: https://imazing.com/profile-editor
Out of curiosity, what's the difference vs Apple's first party "Apple Configurator"? Do you like the GUI better, or does it expose more options?
Re: Improving DNS Privacy with Oblivious DoH
#208The biggest and most consistent downside I see with these DNS enhancements is that it prevents filtering at the network level. Querying nameservers is being pushed into applications themselves to support these new features (such as Chrome and Firefox), which bypasses any system resolvers configured on the host. In most cases there is no way to signal from the network that it is not desirable to do this (Firefox being…
> Querying nameservers is being pushed into applications themselves... I agree: this absurd trend will lead to every app essentially including an entire O/S. There are several reason why OSes provide services to applications and one is that the OS manages the user's configuration (e.g. what devices are plugged in, where and how to resolve names, cacheing data, etc). I also find it rather insane the amount of overhead…
I presume there’s some kind of connection pooling going on ... but yeah you’ve still got the needless verbosity of HTTP for a specialised high volume protocol ...
Re: Improving DNS Privacy with Oblivious DoH
#209The biggest and most consistent downside I see with these DNS enhancements is that it prevents filtering at the network level. Querying nameservers is being pushed into applications themselves to support these new features (such as Chrome and Firefox), which bypasses any system resolvers configured on the host. In most cases there is no way to signal from the network that it is not desirable to do this (Firefox being…
I don't know much about the tech, but would it be possible to setup your own local DNS server that your machines point to, and do the filtering within that DNS server?
Yep! If you have a Raspberry Pi, look into Pihole. Some routers have this capability too.
Re: Improving DNS Privacy with Oblivious DoH
#210Until we get rid of SNI[1] in HTTPS for good there will still be providers (like my ISP) that do deep packet inspection on SNI and kill the connection right away if you happen to visit a forbidden site (and this was western Europe, yesterday, on a site behind CloudFlare) [1] https://en.m.wikipedia.org/wiki/Server_Name_Indication
Part of the counter-argument that has been so prevalent on HN (most recently: [0]) is that when you prevent middlemen on your network from being able to see what website you're browsing, you're doing exactly that: preventing anyone, even a trusted network administrator, from being able to inspect traffic. I'm all for DoH and ECH since US ISPs have a history of inspecting and logging traffic, but it seems like there s…
The vast majority of users do not have a "trusted network administrator"; they have a hostile upstream network. That's where the defaults come from. Trusting the network (or anything outside of the device itself) should always be a non-default setting, and nothing from the network should be able to change that setting. You should have the option of configuring a device you own and control to make its traffic inspectable, but that should never be the default.