Metadata privacy is very hard to solve and traffic analysis of non-Tor traffic is pretty accurate, which is also applicable to CDN traffic regardless of how well DNS is protected.
Improving DNS Privacy with Oblivious DoH
181–190 of 367 posts
Re: Improving DNS Privacy with Oblivious DoH
#182At what point should we just throw out IP out of the window and figure out something new ? OK maybe not IP since all hardware infrastructure is based on it, but the whole idea of associating services to publicly open ports on the target machine. I'm thinking connections should be encrypted at the operating system level and then services would plug in at some higher level in a way that cannot be detected by outside observers.
Re: Improving DNS Privacy with Oblivious DoH
#183The 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?
Re: Improving DNS Privacy with Oblivious DoH
#184Earlier quoted context omitted.
How can they trivially bypass this local filtering? If the router is redirecting all port 53 traffic, there is no way to bypass aside from some alternate name resolution scheme.
How well does the redirect scheme work for a device that connects to a central DNS server listening on, say, port 5353 instead? What about 80 or 443?
Well, it’s more complicated, but in theory you could do some deep packet inspection that understands the protocols: personally, I’d use this to break DoH connections (for every host name seen in SNI, attempt a DoH query, if it resolves, reset the connection) and attempt to force everything to fall back to plain DNS. Then, whitelist a couple outbound ports (on most networks, maybe just 443 + 53?) and block VPNs.
Re: Improving DNS Privacy with Oblivious DoH
#185No hubris here at all.
But seriously, fuck this protocol and fuck every other BigCorp-sponsored protocol to remake the Internet. We the People Who Implement Protocols are too busy keeping the lights on to chase incremental, nice-to-have improvements.
Re: Improving DNS Privacy with Oblivious DoH
#186Earlier quoted context omitted.
How can they trivially bypass this local filtering? If the router is redirecting all port 53 traffic, there is no way to bypass aside from some alternate name resolution scheme.
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.
Re: Improving DNS Privacy with Oblivious DoH
#187The title of the article is really misleading. I though of a succesor to IPv6 and not DNS. It shouldn't say "internet protocol", thats technically not correct
Re: Improving DNS Privacy with Oblivious DoH
#188It bothers me how "privacy" has been redefined in recent years to mean "encrypted" and not "surveillance-resistant". We keep building things that make more requests I can't terminate locally, e.g. to a PiHole.
Never forget the lesson in "Using Metadata to find Paul Revere": https://kieranhealy.org/blog/archives/2013/06/09/using-metad...
Re: Improving DNS Privacy with Oblivious DoH
#189Even better, IMO, would be if all targets were also proxies and a client could choose -- at "query time" -- any combination of (proxy, target) that they prefer.
If you wanted to go a step further, you can even allow "chaining" of proxies, such that the path a query takes might be, in an extreme example, similar to how Tor operates:
Client -> Proxy 1 -> Proxy 2 -> Proxy 3 -> Target -> Resolver
Anyways, this is kinda sorta interesting, I guess, but honestly I'm more excited by and looking forward to the (hopefully!) eventual adoption and roll-out of "DNS SVCB and HTTPS RRs" [0] -- one of the other I-Ds (linked in the OP) on which ODoH is built -- and I suspect many other HN'ers will be as well (although I'd happily settle for SRV RR support in browsers).
--
[0]: https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-02
Re: Improving DNS Privacy with Oblivious DoH
#190Until 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…
> it seems like there should be a way to manage the devices on your network
Administering devices with network settings is convenient, but rapidly vanishing because there's no technical difference between you administering your local network and a totalitarian ISP administering their users.
My ways of dealing with the modern world, in order of preference:
1. Use Free software, so that devices develop user-empowering features instead of being locked down.
2. Firewall all general Internet access from a device/VM, and let it talk to local network devices only.
3. Firewall the device/VM from accessing most of your network, allow Internet access (ideally through a VPN), and inspect the hardware to make sure there aren't microphones or cameras.