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

331–340 of 367 posts

Re: Improving DNS Privacy with Oblivious DoH

#331

Post by yardstick »

jiggawatts wrote: post #306
yardstick wrote: post #243

Earlier quoted context omitted.

DoH is highlighting the security nightmare that is AWS, GCP, Azure, Cloudflare etc with their reverse proxies and virtual hosts, making it impossible to safely restrict a network from communicating with only a specific cloud-hosted service. Also often perfect security isn’t required. Doors with locks are good, but useless if the burglar just breaks the full length glass window next to it. They still serve a purpose,…

The biggest mistake I see in public cloud fundamental architecture is that it uses IPv4 end-to-end, instead of just as a compatibility add-on to native IPv6 networking. Literally all of the security issues caused by the public cloud network architecture instantly evaporate with IPv6, as well as much of the configuration complexity. No more private networks with non-routable addresses! Instead you get a public-routabl…

Due to consumer privacy concerns there will always be people wanting a high degree of anonymity when accessing services, regardless of IPv4 or IPv6. Both from consumers and the people running the services. Right now CDNs provide this privacy using TLS with ESNI. This won’t go away with IPv6. Likewise with DDoS concerns some will want to put CDNs and cloud reverse proxies in front of their services, intermingled with lots of other services.

The solution of dedicated IPv4/IPv6 is necessary for proper network control. But for the reasons above many won’t do so.

Also IPv6 is fundamentally not ready for real world use within small/medium businesses and homes IMO. I know you were talking about IP networking within clouds, forgive me, this rant isn’t aimed at that, it’s just my general IPv6 is not ready rent. At least not without NAT. Why?

- Can’t just simply put one IPv6 router/firewall behind another. Not all IPv6 routers support DHCP-PD, and even if they did, you could have 2-3-4 levels of routers/firewalls at a business. I’m not making this up- retail/gas/food industries often have a plethora of networks at a location, and the business/franchise owner is not tech literate, or even if they were, the equipment is managed by third party vendors and they don’t want to customise their IP network for each location. It makes for messy deployment and maintenance.

- Can’t just simply open a firewall rule on the main site router to forward say HTTPS to an internal service. Why? Not all ISPs give static IPv6 prefixes, not all PCs/servers/devices support DHCP6 for static leases, and then there’s IPv6 privacy addresses. Yes, you can statically configure (only if ISP is static too!). No, I don’t want to open the port to all devices on the LAN and no I can’t rely on each device to be running their own firewall (let alone a properly configured one!).

- WAN failover / multiple ISPs is hard. You have a fibre primary feed, and a secondary cellular/5G feed. Each has different IPv6 addresses. How do you ensure the right ISP is used at any given point? IPv6 shifts this decision to the client. This makes load balancing and policy based traffic routing (eg VoIP over fibre 1, FTP over fibre 2, etc). Also the cost of using a multi-homed IPv6 subnet & BGP in a SME/retail business is out of the question (plus the cellular ISP wouldn’t support it anyway).

All the above works fine out of the box with IPv4 and NAT. It’s bread and butter easy. At the cost of not having dedicated unique public IPs but these places simply don’t need them.

What IPv6 should have done to ensure a smooth migration is allowed for NAT from the very start. That would have let everyone who needed public IPs get them straight away, and those that didn’t to still migrate anyway with as little drama as possible. But it’s just not the case, NAT has been slowly added but it’s support is far from ubiquitous that IPv4 has.

Re: Improving DNS Privacy with Oblivious DoH

#332

Post by yardstick »

acdha wrote: post #275
yardstick wrote: post #243

Earlier quoted context omitted.

DoH is highlighting the security nightmare that is AWS, GCP, Azure, Cloudflare etc with their reverse proxies and virtual hosts, making it impossible to safely restrict a network from communicating with only a specific cloud-hosted service. Also often perfect security isn’t required. Doors with locks are good, but useless if the burglar just breaks the full length glass window next to it. They still serve a purpose,…

> DoH is highlighting the security nightmare that is AWS, GCP, Azure, Cloudflare etc with their reverse proxies and virtual hosts, making it impossible to safely restrict a network from communicating with only a specific cloud-hosted service. This problem goes back a lot further than that — even prior to having CDNs in common usage you had plenty of different clients sharing IP space at hosting companies and the real…

> Trying to hijack DNS is only useful when you control the network but neither the client or server.

This is a very common scenario in retail and SME businesses where you can’t control the on site hardware, eg fuel pumps or CCTV or cash registers or footfall counters or vending machines or whatever, and you can’t control what IPs they talk to. But you still have an obligation to minimise their network access.

Unfortunately they use services hosted on the cloud in dynamic IPs, so you either need to MITM TLS (can’t, no way to change the trusted CA list in these devices), or you need to MITM DNS / SNI. It’s not perfect security, and ideally the business simply wouldn’t buy such poorly securable products, but technology decisions are very rarely vetoed by security considerations, especially when cost is a factor. This is an example of the appropriate level of security for the business risk appetite. Telling the business to buy products that can be locked down perfectly is normally a non-starter.

Re: Improving DNS Privacy with Oblivious DoH

#333

Post by _0w8t »

vim1234 wrote: post #305
stevepike wrote: post #145

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…

Yeah it is true, but the problem is if DoH with its privacy features come along it will be literally impossible to block ads with PiHole, as all DNS quesries will be encrypted (which DoH does ofc rihgt now). So no ability to block ads in TV or malicious domains that IoT deviced connect to or even blocking Windows, macOS telemetry network wide as all DNS requests will be encrypted which they are not as of right now.

It will be possible, just harder. I will not be surprised if there will be services where one can get a database of IP addresses of bad domains and one could block that, the same way one does with spammers. Surely it may block sites that share hosting on those domains, but it then it puts pressure on sites to avoid such sharing sharing.

Re: Improving DNS Privacy with Oblivious DoH

#334

Post by saurik »

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/

? On Windows this is trivial to implement as you can just set the resolver to DNS on localhost; the only reason iOS needs something special is because you can't run servers/daemons.

Re: Improving DNS Privacy with Oblivious DoH

#335

Post by saurik »

JoshTriplett wrote: post #250
judge2020 wrote: post #211

Earlier quoted context omitted.

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/

This is exactly why browsers support doing their own name resolution: because some OSes advance much more slowly.

But instead of it being in the browser, it should be a separate app that upgrades all apps that use the native resolver.

Re: Improving DNS Privacy with Oblivious DoH

#336

Post by heroprotagonist »

xg15 wrote: post #262
stevepike wrote: post #145

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…

If I get access to those devices, yeah, sure. But in practice, I'd argue this actually reduces privacy for users, as it gives apps and devices a secure path through the network which cannot be monitored by any intermediary - including the user of the app or the owner of the device themselves. So no chance to find out what kind of data is being transmitted there either. To me, DoH seems less about protecting the user…

One way to limit this would be to add IP resolved through an approved resolver to a temporarily allowlist for a firewall. The firewall would default-deny outbound network requests. Allowlisted IP would be permitted, but be removed from the list after the TTL for the DNS request expires.

Of course, you'd have to add in some permanent exceptions once you realize just how much hardware and software implodes as a result of this.

Some expected, like peer-to-peer applications, though those allow you to define an outbound ephemeral port range you can limit them to (except perhaps for some poor implementations in commercial game launchers trying to offload bandwidth costs). So some are fairly easy to define.

Others you'll have to log and see. Like your Google Home hardware..

I got some minis and disabled the mics since they had hardware switches. I hacked around a bit emulate sending them audio programmatically and discovered they use external DNS and therefore couldn't resolve the local network web server hosting the audio clips I wanted to play. So I had to permanent-lease the hostname's IP and give it an IP address.. They were already bypassing local DNS blockers years ago.

Re: Improving DNS Privacy with Oblivious DoH

#337

Post by anonypla »

One should also note that, even if you use ODoH, eSNI and even Tor (or any VPN service), your ISP could still reliably fingerprint your web access activity at the source using deep learning with over 96% accuracy as shown in this study (https://distrinet.cs.kuleuven.be/software/tor-wf-dl/).

So while ODoH is a good thing (and also recommended in this study which has shown the weaknesses of DoH/DoT https://www.esat.kuleuven.be/cosic/publications/article-3153...) and is very similar to DNS over Tor with a DNS hidden service resolver (which Cloudflare also provides). It won't prevent a skilled and motivated adversary from determining your activity and possibly apply censorship.

I would guess that a solution to mitigate these would be to use an hybrid solution of VPN over Tor (or Tor over VPN) while also using DNS over Tor or ODoH and eSNI.

Re: Improving DNS Privacy with Oblivious DoH

#338

Post by GoblinSlayer »

quicksilver03 wrote: post #328
judge2020 wrote: post #215

Earlier quoted context omitted.

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

If you control DHCP and know the MAC address of those embedded devices, you can serve them a non-existing gateway so that they simply won't have a path outside of your home network. Of course, that assumes IPv4, whereas with IPv6 and SLAAC I believe the only way is to firewall them out.

If they won't ask you to drink a verification can to proceed.

Re: Improving DNS Privacy with Oblivious DoH

#339

Post by zem »

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.

do you own a smart tv in your house?

Re: Improving DNS Privacy with Oblivious DoH

#340

Post by buran77 »

heroprotagonist wrote: post #336
xg15 wrote: post #262

Earlier quoted context omitted.

If I get access to those devices, yeah, sure. But in practice, I'd argue this actually reduces privacy for users, as it gives apps and devices a secure path through the network which cannot be monitored by any intermediary - including the user of the app or the owner of the device themselves. So no chance to find out what kind of data is being transmitted there either. To me, DoH seems less about protecting the user…

One way to limit this would be to add IP resolved through an approved resolver to a temporarily allowlist for a firewall. The firewall would default-deny outbound network requests. Allowlisted IP would be permitted, but be removed from the list after the TTL for the DNS request expires. Of course, you'd have to add in some permanent exceptions once you realize just how much hardware and software implodes as a result…

> add IP resolved through an approved resolver to a temporarily allowlist for a firewall

That ship has sailed now that some of the functionality provided by TCP moved up to HTTPS. Whereas in the past you could expect the same IP to expose DNS on port 53, FTP on port 21, or HTTP on port 80, now the same IP will serve you everything over the handy port 443.

So a software developer can very well go this route if they want to obfuscate DNS calls and you wouldn't be able to discriminate the traffic like you would today with ports.

Any global (OS/network) policies become meaningless if your browser or app decide to only ask the DoH resolver "who is google.com" or "who is facebook.com" once, and have all subsequent queries go that way inside an encrypted HTTPS stream.

Post reply on HN