Live data from Hacker News

Improving DNS Privacy with Oblivious DoH

blog.cloudflare.com

361–367 of 367 posts

Re: Improving DNS Privacy with Oblivious DoH

#361
post #308
post #304

Earlier quoted context omitted.

There is no system that both allows communication between multiple parties and is infinitely resilient to a sufficiently determined, large, and well-funded group of people with guns. What we can do with design and architecture is make each breach of communications security consume greater resources than unencrypted DNS, unencrypted HTTP, and unencrypted email.

There is no bit of land left on Earth where I could go live and not be governed by a determined, large, and well-funded group of people with guns. Perhaps it's time to start building with them in mind first?

There actually is unclaimed land left on Earth. I know there's a bit between Egypt and Sudan. Claiming the land would worsen their claim on a different, better, piece of land that they both claim is theres; so neither does.

Unsure of the status of non-government large, well funded groups of people with guns there is though.

Re: Improving DNS Privacy with Oblivious DoH

#362

Why encrypt the first hop? Why isn't this just plain DoH with a simple CONNECT forward proxy to 1.1.1.1, like Signal's Giphy proxy [1]? [1] https://signal.org/blog/signal-and-giphy-update/

Answering my own question.. A cryptographer friend offered an answer to this question: The network operator may be the same as or colluding with the target resolver, defeating the anonymization of the proxy.

Once we say we need encryption on the first hop, then I can see the logic in using a stateless protocol instead of TLS for the second hop, to avoid TLS-in-TLS and all the round trips associated with that.

Side note: It'd be cool if these new protocols used the more generic Noise Protocol Framework [1] instead of a custom, more specialized protocol they just came up with like HPKE [2].

[1] http://noiseprotocol.org/noise.html [2] https://www.ietf.org/id/draft-irtf-cfrg-hpke-06.txt

Re: Improving DNS Privacy with Oblivious DoH

#363

Earlier quoted context omitted.

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…

> Due to consumer privacy concerns there will always be people wanting a high degree of anonymity

"No one can have glass windows in their homes, because a few people like to walk around naked at home, and they're worried about their privacy."

or

"You can't have steak, because if a baby were to eat it, they might choke."

> Right now CDNs provide this privacy

Nothing at all stops you using CDNs with IPv6.

> Also IPv6 is fundamentally not ready for real world use within small/medium businesses and homes IMO.

The protocol has been ready for 10+ years. I'm on an IPv6-enabled home network right now, and it works just fine.

As for the rest of your arguments: They're a side-effect of there being insufficient pressure on ISPs to do their jobs.

If public cloud providers primarily used IPv6, that would very rapidly force ISPs to get their act together and fix their woeful IPv6 support!

Re: Improving DNS Privacy with Oblivious DoH

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

> Networks must not have the ability to intercept device traffic unless the device administrator (not the network administrator) configures it as such

The device admin of an iPhone is Apple, the device admin of a non-rooted Android phone is Google, the device admin of a Windows 10 PC is Microsoft and the device admin of a smart TV is likely Samsung. Is that the point you want to make?

All of those companies have incentives to collect user data and are known to push user-hostile changes. They also either have known ties with the NSA or can be coerced via National Security Letters, making even the tired point about "defense against state actors" moot. Do you trust any of them?

If, say, Tencent brought a phone to market in the US that turns out wildly popular but happened to exchange vast amounts of data with servers in China, would you be ok with that?

Most devices today have locked-doen bootloaders, so I don't actually have a choice about the device admin for my device. The position of network admin can be abused, too, but at least there is a possibility I can fill this position myself or can delegate it to someone who I trust.

> Ultimately, your choice with uncooperative devices is "block the device or don't", along with "replace it with a cooperative device".

Right now there are huge market incentives to make devices ever more uncooperative. Unless something changes, the choice for consumers will likely be soon "tolerate an uncooperative device and don't block it - or opt out of technological progress altogether".

> That's fundamentally not possible; any mechanism usable by 'good' network admins can be used by 'bad' network admins.

This argument doesn't get any more coherent no matter how often it's repeated. Somehow the tech industry keeps arguing that the key to any kind of mandatory backdoor will leak with mathematical certainty - while employing that exact same kind of backdoor for their own purposes without any worry - in the form of forced updates and forced telemetry. How exactly can the same technology be a security risk when used by a government but a security best practice when used by a private company?

> We absolutely need full control over our own devices, but many of the people most capable of fighting for that control got complacent about it because a subset of people could hack around it with local network interception stunts.

So then what would be your idea how to gain control?

Re: Improving DNS Privacy with Oblivious DoH

#365

Earlier quoted context omitted.

I am cynical and maybe paranoid. Be careful what you wish for What I think will end up happening, most of the devices will go encrypted route [1]. Most things will run over https, and with encrypted sni, you won't even be able to block domains. Encryption will be backdoored by governments (and of course other people that will reverse those backdoors or have friends in LEA ). End result is encryption that people are c…

People advocating a 100% encrypted Internet are also many of the same people fighting tooth and nail against backdoored or otherwise broken encryption. It doesn't make sense to say that encryption will be backdoored so we should use plaintext. We should fight for security across the board, and fight against any threat to that security.

Again, this fight doesn't make any sense if that very same encryption is then used against us.

Re: Improving DNS Privacy with Oblivious DoH

#366

Earlier quoted context omitted.

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

Most of the OS level resolvers just forward to the resolver provided via DHCP. Which is fine for enterprise, but for home users means using the ISPs resolver, which can track users and has a history of injecting ads on failed resolutions.

Not to mention the user interface for configuring them has never evolved beyond /etc/hosts and the total disaster that is /etc/resolv.conf (on modern linux distros).

The fact that I have to run a separate device such as pi-hole to intercept DNS rather than just point my OS resolver to a blacklist indicates how OS level resolvers have not kept up with the use cases people are asking of them.

And of course, no support for DoH or DoT or even DNSSEC.

Re: Improving DNS Privacy with Oblivious DoH

#367

Earlier quoted context omitted.

You can bypass SNI inspection [0] with tools like GreenTunnel [1] and Intra [2]. [0] https://twitter.com/vinifortuna/status/1304189371688660992 [1] https://news.ycombinator.com/item?id=22654737 [2] https://getintra.org/

Thanks for the link, just tried Green Tunnel on the use case where my ISP is blocking me and just managed to change the error from PT_CONNECT_RESET_ERROR to PR_END_OF_FILE_ERROR. Side note, looks like that if installed by snap on Ubuntu 20.10 it cannot automagically change the proxy configuration in Gnome green-tunnel:system-proxy [SYSTEM PROXY] error on SetProxy (Error: Command failed: gsettings set org.gnome.system…

Does Intra work?
Post reply on HN