Live data from Hacker News

Improving DNS Privacy with Oblivious DoH

blog.cloudflare.com

311–320 of 367 posts

Re: Improving DNS Privacy with Oblivious DoH

#311
post #280

Earlier quoted context omitted.

Any firewall worth its salt can do this with IPv6 as well. There's nothing on a technical level preventing it.

iptables? Of course it's technically possible, it's all just packets of data that you can change, at the end of the day. I just meant that the easy way to do it (AIUI) went away with IPv6 because you were never supposed to need to do that, and with v6 you 'don't'. It's not like the purpose of firewalls is redirection.

Create a loopback interface and assign it the IP address you want redirected, then have your DNS resolver bind to those IP's.

Re: Improving DNS Privacy with Oblivious DoH

#314

Earlier quoted context omitted.

> Without some way to do that ISPs will not be able to get away with such customer hostile behavior. I guess it won't take long until the first community or HOA decides to ban Starlink dish installations for faked "optical nuisance" issues.

Faked? What other reason would an HOA have to ban them?

A cable company offers to wire the neighborhood saving the builder some money. In exchange the HOA setup by the builder bans satellite dishes. In more annoying cases the HOA negotiates a group plan included in your HOA assessment bill; that really stifles competition because paying for an alternative on top of cable is irrational. The FCC banned satellite dish bans back in the 90s.

Apartment building operators still do this scam. The incumbent cable company will share revenue in exchange for the landlord refusing any competitor wiring.

Rent seeking in ISP markets is peanuts compared with zoning though. If real estate was much less supply constrained landlords would never fathom annoying a customer with inferior utilities.

Re: Improving DNS Privacy with Oblivious DoH

#315
post #259
post #220

Earlier quoted context omitted.

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.

Yes. The alternative is what I call "totalitarian liberalism" - it's not going to be communism, it's not going to be fascism, it's going to look a lot more like IKEA, and while it may be easier to physically step out of line, the incentives structure is rapidly converging on finding ways to keep you corralled in invisible ways.

Re: Improving DNS Privacy with Oblivious DoH

#316
post #280

Earlier quoted context omitted.

Any firewall worth its salt can do this with IPv6 as well. There's nothing on a technical level preventing it.

iptables? Of course it's technically possible, it's all just packets of data that you can change, at the end of the day. I just meant that the easy way to do it (AIUI) went away with IPv6 because you were never supposed to need to do that, and with v6 you 'don't'. It's not like the purpose of firewalls is redirection.

I thought that iptables was the easy way to do it? (Both for IPv4 and IPv6.)

NAT66 is an experimental (10 years old IIUC!) RFC for one-to-one IPv6 mapping. While there's no RFC specifying an official method of masquerading behind a single address, AFAIK iptables "just works" (as long as you aren't running FreeBSD).

Re: Improving DNS Privacy with Oblivious DoH

#317
post #266

Earlier quoted context omitted.

Complain to who exactly? > people taking what devices could already do and standardizing it so that anyone can use it in a more uniform way. In this case, standardization makes a huge difference. Before DoH, this was theoretically possible, but needed enormous effort to pull off: The simplest thing a device could do was to hardcode custom DNS servers - but the network admin could easily bypass that by redirecting the…

> With DoH, there are publicly accessible servers that accept requests over plain HTTPS Which is a good thing for end users on balance. The Internet is going 100% encrypted and that's a good thing. This helps towards that goal. Relying on unencrypted traffic will no longer work. Networks must not have the ability to intercept device traffic unless the device administrator ( not the network administrator) configures i…

> there continue to be threads full of arguments that amount to "It should be possible for 'good' network admins to intercept traffic from devices that don't trust them, but 'bad' network admins shouldn't be able to intercept traffic from devices that don't trust them"

That's not what I see at all.

I see people pointing out that DoH hurts privacy and reduces control for end users by providing a convenient turnkey solution for device vendors to bypass filtering at the network level.

I also see it pointed out that DoH could have been specified in a way that facilitated filtering for the local network. Given that it's so obviously possible, the fact that it wasn't speaks volumes.

Note that (IIUC) your ISP can still see which sites you visit because TLS still transmits the FQDN in plaintext (https://security.stackexchange.com/questions/86723). Even if that stopped happening tomorrow, the destination IP would still be visible (not quite as bad but still reveals a huge amount of information). On top of all that, DNSSEC already exists which allows you to verify the authenticity of the query result. As such, the argument in favor of DoH would seem to be limited to preventing your DNS resolver (but not your ISP or VPN!) from tracking which sites you visit. I don't find that to be very compelling in light of the immediate downsides.

Re: Improving DNS Privacy with Oblivious DoH

#318

Earlier quoted context omitted.

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…

You can snoop SNI and use that to block traffic, right? In another thread, someone suggested also stripping the keys for encrypted SNI from DNS queries which, when combined with a firewall that attempts to make a DoH query to every new SNI name it sees might potentially work.

For now. Encrypted SNI is in development and will eventually be used by devices and apps that want to do this sort of thing and hide what they're doing.

Re: Improving DNS Privacy with Oblivious DoH

#319

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…

Thanks for spelling it out like that - I think I might see the bigger picture here now. DoH (which incorporates DNSSEC under the hood) to protect the name lookup. IPv6 to provide unique addresses for every single service you connect to. The complete removal of SNI (as a security threat) and ESNI (as unnecessary complexity).

Pi-hole type filtering is then implemented based on IP blocks instead of DNS queries. Any unrecognizable IP address is default denied. Tracking, analytics, and ads could still be proxied by a remote host, but that can already happen anyway.

Of course, your ISP (or VPN, or anyone else along the network path) could employ the exact same approach to determine the services you connect to. Which leads me right back to DoH being largely pointless and Tor or similar being a hard requirement for actual privacy. Unless I'm missing something?

Re: Improving DNS Privacy with Oblivious DoH

#320
post #266

Earlier quoted context omitted.

Complain to who exactly? > people taking what devices could already do and standardizing it so that anyone can use it in a more uniform way. In this case, standardization makes a huge difference. Before DoH, this was theoretically possible, but needed enormous effort to pull off: The simplest thing a device could do was to hardcode custom DNS servers - but the network admin could easily bypass that by redirecting the…

> With DoH, there are publicly accessible servers that accept requests over plain HTTPS Which is a good thing for end users on balance. The Internet is going 100% encrypted and that's a good thing. This helps towards that goal. Relying on unencrypted traffic will no longer work. Networks must not have the ability to intercept device traffic unless the device administrator ( not the network administrator) configures i…

> This feels like the geek version of DRM fallacies or the fallacies that governments believe about encryption. Somehow, there continue to be threads full of arguments that amount to "It should be possible for 'good' network admins to intercept traffic from devices that don't trust them, but 'bad' network admins shouldn't be able to intercept traffic from devices that don't trust them". That's fundamentally not possible; any mechanism usable by 'good' network admins can be used by 'bad' network admins. (Leaving aside that 'good' and 'bad' are relative.) And worse, people get so invested in their local network interception that once it becomes clear that isn't possible, some will start arguing that their local network interception is more important than general Internet security.

That's not the distinction at all.

It's that you should be able to set up interception on the local network at install time, but all other interception should be blocked. It's extremely possible.

Post reply on HN