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

171–180 of 367 posts

Re: Improving DNS Privacy with Oblivious DoH

#171

Post by TrueDuality »

rubyfan wrote: post #161
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…

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.

Adding in root certificates and performing HTTPS MITM even on your own network is a huge risk on its own. You're basically breaking many layers of security such as certificate pinning that just get disabled with any custom root certificate. Those middleboxes will always break client certificate authentication and you're trusting that they are checking the various revocation lists they should be (CRL/OSCP/various built-in blocklists).

For your basic premise to work, it also means that the MITM middleboxes will need to support the DoH protocols and support recording, and filtering those responses.

Additionally, custom roots certificates will only work on devices that you can actually set a custom root certificate for, a great example is IoT devices. Is your TV suddenly talking to a botnet or was that a legitimate update?

We can argue about whether those middleboxes are even sane to deploy (hint: they're not), but what is historically true is that they are known to update slowly to new protocols, if at all and are known to cause compatibility issues for traffic that is inherently expected to be unchanged. They're enough of a problem at the _TCP_ layer that QUIC was explicitly designed that minimal information is available in the protocol headers so middleboxes would have less to mess with.

Re: Improving DNS Privacy with Oblivious DoH

#172

Post by j16sdiz »

crispyporkbites wrote: post #129
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…

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.

Because, DNS, like default gateway and ip address, are configured by DHCP? Zoned DNS server for intranet is very common.

Re: Improving DNS Privacy with Oblivious DoH

#173

Post by g42gregory »

DoctorOW wrote: post #165
g42gregory wrote: post #164

Do I understand this correctly that if DoH is implemented, none of the firewalls will be able to block the web sites? Including the pi-hole firewalls, as an example. If that's the case, this situation can't stand for long. Does this meant that the DoH would need to be extended to allow firewalls to decrypt it? If not, here is a PaloAlto Networks blog advertising capability to block all DoH traffic, presumably at work…

What's stopping your PiHole from just getting its own HTTPS cert?

I am still a noob to the networking. I just started using OpenWrt router to manage my home network. OpenWrt has an option to enable DNS over HTTPS. Is this all one would need to do in order for the firewall rules still work with the DoH browsers?

Re: Improving DNS Privacy with Oblivious DoH

#174

Post by admax88q »

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…

Pi-hole is still very much niche, and outside of that and enterprise network admins, the majority of users are stuck using the trash resolver of their operating system directed to the trash DNS servers of their ISP.

If DNS level blocking ever becomes popular enough, malware authors will change their systems to not use the system's DNS, or to use hard coded DNS over TLS/HTTP servers that they know will serve them the data they want.

Preventing proprietary applications from doing malicious things is a constant cat and mouse game. Pi-hole works well for now, I would argue, because it's not popular enough to put a big enough dent in the success rate of malware.

Re: Improving DNS Privacy with Oblivious DoH

#175

Post by RossM »

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.

Using Cloudflare with DoH is documented here: https://docs.pi-hole.net/guides/dns-over-https/

You essentially run a little proxy server on your pihole setup, and configure pihole to use it as your upstream dns resolver.

E.g., a proxy server running at 127.0.0.1:5053 which uses the Cloudflare ipv4/ipv6 DNS over HTTPS endpoints. This can also use other DoH endpoints as desired:

    /usr/local/bin/cloudflared proxy-dns \
      --port 5053 \
      --upstream https://1.1.1.1/dns-query \
      --upstream https://1.0.0.1/dns-query \
      --upstream https://2606:4700:4700::1111/dns-query \
      --upstream https://2606:4700:4700::1001/dns-query

Re: Improving DNS Privacy with Oblivious DoH

#176

Post by chipb »

fiddlerwoaroof wrote: post #167
acdha wrote: post #151

Earlier quoted context omitted.

The problem is that the things you most want to block can trivially bypass your local DNS filtering - DoH is just standardizing something which has been done for decades. The only effective measure is to block outbound network access and require use of a proxy, possibly optimized by allowing direct traffic only from clients with functioning endpoint monitoring agents.

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?

Re: Improving DNS Privacy with Oblivious DoH

#177

Post by vageli »

chipb wrote: post #176
fiddlerwoaroof wrote: post #167

Earlier 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?

> How well does the redirect scheme work for a device that connects to a central DNS server listening on, say, port 5353 instead? How about 80 or 443?

Just because it is not a silver bullet doesn't mean it is not effective for a large percentage of users.

Re: Improving DNS Privacy with Oblivious DoH

#178

Post by TrueDuality »

admax88q wrote: post #174
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…

Pi-hole is still very much niche, and outside of that and enterprise network admins, the majority of users are stuck using the trash resolver of their operating system directed to the trash DNS servers of their ISP. If DNS level blocking ever becomes popular enough, malware authors will change their systems to not use the system's DNS, or to use hard coded DNS over TLS/HTTP servers that they know will serve them the…

pi-hole is the most recognized name on here, but I think you're wrong about DNS level blocking. There are lot of home routers that have started integrating that feature natively. A few examples that I know off hand:

- Motorola MH7022

- Eero

- Disney Circle

Basically any of them that say "content filtering" in their product sheet are using DNS level filtering.

> ...the trash resolver of their operating system...

I'm very curious why you think the well tested, vetted, and constantly updated resolvers built into OS's are "trash". Is it just because most don't have support for DoH or DoT?

Re: Improving DNS Privacy with Oblivious DoH

#179

Post by acdha »

fiddlerwoaroof wrote: post #167
acdha wrote: post #151

Earlier quoted context omitted.

The problem is that the things you most want to block can trivially bypass your local DNS filtering - DoH is just standardizing something which has been done for decades. The only effective measure is to block outbound network access and require use of a proxy, possibly optimized by allowing direct traffic only from clients with functioning endpoint monitoring agents.

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 connects on 443 to a major hosting provider, like half the apps you run, searches Google.com, Twitter, etc., or hits an ad network for a keyword selected by the attacker.

In every case, once they get the server(s) to connect to you lose all further visibility unless you’re blocking 443 and forcing traffic through an inspection proxy.

Re: Improving DNS Privacy with Oblivious DoH

#180

Post by eh78ssxv2f »

What a stark difference between Google and Apple/Cloudflare.

Apple/Cloudflare are working on privacy-friendly protocols that reduce the amount of information exposed to them.

At exactly the same time, Google is working on proxying browser traffic through them without any consents [1].

[1]: https://news.ycombinator.com/item?id=25337995

Post reply on HN