Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Improving DNS Privacy with Oblivious DoH

blog.cloudflare.com

Post reply on HN
Print view View original

211–220 of 367 posts

Re: Improving DNS Privacy with Oblivious DoH

#211

Post by judge2020 »

saurik wrote: post #205
TrueDuality wrote: post #119

The 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 an…

iOS and MacOS technically have this (requires a profile[0]) but Microsoft will probably drag their feed on this for the next 2 years with the amount of enterprise customers they have to keep happy; and, given that the network adapter config is still based on Aero controls, they're probably in no rush to add more configuration options before upgrading it to Metro controls.

0: https://paulmillr.com/posts/encrypted-dns/

Re: Improving DNS Privacy with Oblivious DoH

#212

Post by notwedtm »

TrueDuality wrote: post #119

The 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…

Giving the user the ability to expose these requests by sending an HMAC of the domain to a local resolver could help with the privacy portion, but still allow for custom routing based on context.

Re: Improving DNS Privacy with Oblivious DoH

#213

Post by OJFord »

What's the advantage of this over specifying a DoH provider (as we do today with plain DNS)?

Unfortunately I suppose the only way to really do that is with a resolv file (adlist/blocklist) of DoH hosts (which exist) but instead of pointing to 0.0.0.0, point to .

Edit - d'oh! I see it now - that would mean DoH provider knows query and IP, whereas here the ODoH proxy knows your IP but not the query. Nice.

Re: Improving DNS Privacy with Oblivious DoH

#214

Post by crispyporkbites »

gumby wrote: post #136
crispyporkbites wrote: post #129

Earlier quoted context omitted.

why should DNS be handled at the system layer and not by applications? There's zero controls in place to stop this so I don't see why it's assumed that every application developer will want to use system defaults and not override it.

> I don't see why it's assumed that every application developer will want to use system defaults It's the user's machine not the application developer's.

But it’s not under the users control if they install an app- there’s nothing hard that prevents the abuse. Now if the OS had a system wide / network level proxy that checks the correct DNS calls are getting made and overrides with a user chosen default, then you’d have something.

But we don’t, we just have a default

Re: Improving DNS Privacy with Oblivious DoH

#215

Post by judge2020 »

stevepike wrote: post #160
TrueDuality wrote: post #147

Earlier quoted context omitted.

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 privac…

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":

https://news.ycombinator.com/item?id=25315172

Re: Improving DNS Privacy with Oblivious DoH

#216

Post by judge2020 »

fiddlerwoaroof wrote: post #184
chipb wrote: post #176

Earlier quoted context omitted.

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.

> or every host name seen in SNI

Not going to be possible in a few years or so:

https://news.ycombinator.com/item?id=25344311

Re: Improving DNS Privacy with Oblivious DoH

#217

Post by dperfect »

crumbshot wrote: post #72

This 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…

Exactly what I was thinking. It doesn't even really help to run your own proxy on a server somewhere, because although the target wouldn't know for sure what the client's IP address is, queries from just one IP are likely to be easily correlated (statistically or otherwise).

So you convince some neighbors to use your proxy... As the number of clients grows, so does the uncertainty that the person running the proxy isn't colluding with the target, so you're back to the same trust issue that you were trying to solve in the first place.

Re: Improving DNS Privacy with Oblivious DoH

#218

Post by 1over137 »

judge2020 wrote: post #211
saurik wrote: post #205

Earlier quoted context omitted.

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 an…

iOS and MacOS technically have this (requires a profile[0]) but Microsoft will probably drag their feed on this for the next 2 years with the amount of enterprise customers they have to keep happy; and, given that the network adapter config is still based on Aero controls, they're probably in no rush to add more configuration options before upgrading it to Metro controls. 0: https://paulmillr.com/posts/encrypted-dns/

Why on earth is a "configuration profile" required for this?

Re: Improving DNS Privacy with Oblivious DoH

#219

Post by vetinari »

specto wrote: post #200
hkt wrote: post #122

Earlier quoted context omitted.

Applications still have fallback though, right? If so, I foresee blocks on DoH/etc to common resolvers like 8.8.8.8 and 1.1.1.1. I'll be blocking them at home on the assumption that I only want regular DNS lookups so I can point them to my own DNS server etc.

I have blocked 1.1.1.1 and 8.8.8.8 and noticed some devices behave very badly, often crashing or restarting. Debugging the issue, once I removed the firewall rule they behaved normally. Almost all of the affected devices were google related, Android TV for example.

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.

Re: Improving DNS Privacy with Oblivious DoH

#220

Post by Kalium »

Lammy wrote: post #188

It 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...

As another HN user put it: https://news.ycombinator.com/item?id=25349426

> 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.

Your ability to terminate things locally means that finding Paul Revere with metadata isn't needed. It's a lot of work when you can just directly look at all your country's traffic.

Post reply on HN