Live data from Hacker News

Improving DNS Privacy with Oblivious DoH

blog.cloudflare.com

251–260 of 367 posts

Re: Improving DNS Privacy with Oblivious DoH

#251
post #207

Earlier quoted context omitted.

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?

I do like the UI/UX better; I've always found Apple Configurator to be clunky and non-intuitive.

Re: Improving DNS Privacy with Oblivious DoH

#252
post #234

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…

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…

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.

Re: Improving DNS Privacy with Oblivious DoH

#253

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.

DNScurve never got far in the IETF but I like it:

https://tools.ietf.org/html/draft-dempsky-dnscurve-01

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.

arguably the less important part of the equation

Re: Improving DNS Privacy with Oblivious DoH

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

Firefox and Chrome do yes, but none of these standards specify any kind of fall-back behaviour. There are no guarantees that any specific device or application needs to do that or how. There is a cost to firewall rules like that as well. Who is going to maintain a list of all the IPs on the internet that are hosting DoH servers that could be used? What about the potentially more prolific proxies specified in this pro…

Well, adblock lists exist, DNS block lists exist, this is just something along similar lines that can be tested and aggregated and distributed. Not a perfect solution, but pi-hole as a router or similar could do it.

Re: Improving DNS Privacy with Oblivious DoH

#255
post #228
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.

"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 wish it were that easy but it's very predictable that google will start resolving DoH on plain old "google.com". So will everyone else ... it's not going to be malicious.userhostile.resolver.samsung.com,…

Grim thought, but surely they'd have to be serving from the same IPs?

Re: Improving DNS Privacy with Oblivious DoH

#256

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…

When enterprises own the devices on their networks they can add whatever root certificate they like and MITM filter whatever they like. This makes over the network traffic more secure and does nothing to really impact threat detection. If you don’t own the device then 1) should you be interfering or snooping the traffic at all? 2) if you need to limit threat then subnet clients you don’t own.

Not with TLS1.3 and DoH and ENSI they can’t.

Re: Improving DNS Privacy with Oblivious DoH

#257
DNS privacy for DoH effectively means we all lose the ability to control what our devices are connecting to. In particular, we can't block ads and trackers at the network level. The lack of fallback to regular DNS in the spec means we will choose between devices that track us while they work, or devices that are broken.

Re: Improving DNS Privacy with Oblivious DoH

#258
post #255
post #228

Earlier quoted context omitted.

"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 wish it were that easy but it's very predictable that google will start resolving DoH on plain old "google.com". So will everyone else ... it's not going to be malicious.userhostile.resolver.samsung.com,…

Grim thought, but surely they'd have to be serving from the same IPs?

Right, but do you want to block all access to google.com ?

I, and many users on my home network, use that site a lot :)

Re: Improving DNS Privacy with Oblivious DoH

#259
post #220
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 c…

People in totalitarian regimes aren't safe. This is kind of a given.

What everyone everywhere can resist, though, is corporate surveillance. That's the aim people should have.

Re: Improving DNS Privacy with Oblivious DoH

#260

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…

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 software and Clouflare's ESNI-enabled CDN is an option, but you have to keep making DNS queries to get a key that changes every hour.

Post reply on HN