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.
Improving DNS Privacy with Oblivious DoH
311–320 of 367 posts
Re: Improving DNS Privacy with Oblivious DoH
#312Re: Improving DNS Privacy with Oblivious DoH
#313When you need a log-log plot to make the performance degradation not look so severe, you have issues...
Re: Improving DNS Privacy with Oblivious DoH
#314Earlier 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?
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
#315Earlier 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.
Re: Improving DNS Privacy with Oblivious DoH
#316Earlier 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.
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
#317Earlier 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…
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
#318Earlier 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.
Re: Improving DNS Privacy with Oblivious DoH
#319Earlier 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…
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
#320Earlier 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…
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.