Live data from Hacker News

Show HN: Running the second public ODoH relay

numa.rs

41–50 of 50 posts

Re: Show HN: Running the second public ODoH relay

#41
post #5

Earlier quoted context omitted.

They solve different things. ODoH hides your question, not who you're talking to.

Sure ODoH hides your query but you then turn around and leak the question you just asked as part of the TLS handshake.

Leaked to different parties.

Assuming you don't have ECH, you leak the question (in practical terms) to your ISP, and you leak your question to the DNS provider. With ODoH you plug the latter leak. Plugging that first leak is then still a problem (solved separately) but it's orthogonal to the second.

Even with ECH, where you plug the TLS leak, you have many more holes to plug. IP address might not be shared or might be shared across too few properties, and then traffic profile after the initial connect (to retrieve all the sub-resources) can identify destinations.

Re: Show HN: Running the second public ODoH relay

#42

Earlier quoted context omitted.

Sure ODoH hides your query but you then turn around and leak the question you just asked as part of the TLS handshake.

Leaked to different parties. Assuming you don't have ECH, you leak the question (in practical terms) to your ISP, and you leak your question to the DNS provider. With ODoH you plug the latter leak. Plugging that first leak is then still a problem (solved separately) but it's orthogonal to the second. Even with ECH, where you plug the TLS leak, you have many more holes to plug. IP address might not be shared or might…

It's not limited to the ISP and DNS provider. Thanks to being plaintext it's anyone anywhere along the network path (unless you were already using DoH of course, but sans-ECH is still the entire path regardless).

Anyway I agree with you that plugging leaks is good (notice my adjacent comment). My response there was intended to provide clarification regarding the preceding exchange.

Re: Show HN: Running the second public ODoH relay

#43

Earlier quoted context omitted.

Leaked to different parties. Assuming you don't have ECH, you leak the question (in practical terms) to your ISP, and you leak your question to the DNS provider. With ODoH you plug the latter leak. Plugging that first leak is then still a problem (solved separately) but it's orthogonal to the second. Even with ECH, where you plug the TLS leak, you have many more holes to plug. IP address might not be shared or might…

It's not limited to the ISP and DNS provider. Thanks to being plaintext it's anyone anywhere along the network path (unless you were already using DoH of course, but sans-ECH is still the entire path regardless). Anyway I agree with you that plugging leaks is good (notice my adjacent comment). My response there was intended to provide clarification regarding the preceding exchange.

Going off on a tangent, I wish there were more awareness of how this concentrates power to Cloudflare.

Re: Show HN: Running the second public ODoH relay

#44
post #3

What’s the selling point of ODoH given the low uptake of ECH which means the name of the server you’re talking to is given away anyway?

ODoH selling point is same as DoH selling point: third party DNS providers, e.g., shared caches, want query data for commercial purposes^1

And, funnily enough, they want data from users who are looking for "privacy"

Also, ODoH claims it will hide the client's IP address. ECH, even it were adopted by CDNs and websites, cf. being "supported" by a browser,^2 will not hide the client's IP address

1. Silicon Valley has this bizarre narrative where ISPs are the "bad guys" when it's Silicon Valley who created the online surveillance dystopia we are living in. Truthfully it's a competition over who can collect more data, conduct more surveillance and perform more ad services: Silicon Valley or ISPs. Silicon Valley is generally 100% focused on this as a "business model", cf. selling internet access, they have captured the market and they pose a much greater threat to the user seeking "privacy"

2. Where the browser vendor is Silicon Valley and data collection, surveillance and online advertising services is the "business model"

NB. Third party recursive DNS service has other uses besides "privacy", e.g., avoiding censorship

Re: Show HN: Running the second public ODoH relay

#45

Earlier quoted context omitted.

It's not limited to the ISP and DNS provider. Thanks to being plaintext it's anyone anywhere along the network path (unless you were already using DoH of course, but sans-ECH is still the entire path regardless). Anyway I agree with you that plugging leaks is good (notice my adjacent comment). My response there was intended to provide clarification regarding the preceding exchange.

Going off on a tangent, I wish there were more awareness of how this concentrates power to Cloudflare.

Between so many service operators intentionally purchasing MitM as a service from the cloud providers and the ever increasing proliferation of centralized captcha solutions that work via fingerprinting the entire situation seems increasingly hopeless.

Re: Show HN: Running the second public ODoH relay

#46

Earlier quoted context omitted.

> something people using normal ISPs don't need to worry about It doesn't matter which ISP you're using if the cables are tapped, which they pretty much are.

Please don’t be intentionally tone-deaf. “a nation-state can track my shit therefore it’s not with doing” is a silly, silly, silly approach to security, and does not speak to the concerns of the vast majority of even privacy-focused people.

That's not what I was saying. I'm just saying that if the goal is not to be tracked, that's pretty difficult to achieve with pretty much any normal ISP. Not saying that all forms of tracking are something to be worried about to the point where it's not worth doing defense-in-depth whatsoever... obviously any shred of privacy you can get is good.

Re: Show HN: Running the second public ODoH relay

#47
DoHoT implemented with dnscrypt-proxy is my personally fav way to solve this ... https://github.com/alecmuffett/dohot

speed (over tor) is not a concern either when much of it is served from the cache. alec muffet has the right ideas. but you might want to study his threat-model before copy pasting.

Re: Show HN: Running the second public ODoH relay

#48
post #18
post #16

Earlier quoted context omitted.

The relay sees IP + ciphertext, the target sees question + relay's IP. No single party gets both

What if the relay and target are being operated by the same provider? The relay controls where the question is sent right? They can collude?

"They can collude?"

There are no limitations on what these parties can do with the data they collect or where they can transfer it

Re: Show HN: Running the second public ODoH relay

#49
post #3

What’s the selling point of ODoH given the low uptake of ECH which means the name of the server you’re talking to is given away anyway?

It means you can use a decently fast DNS server like Cloudflare without the major privacy problems of using Cloudflare. Or DNS4EU, or any non-ISP DNS server really. Your ISP snooping on you with SNI logging is something people using normal ISPs don't need to worry about, but feeding all your data into a profit-driven company is.

[deleted]

Re: Show HN: Running the second public ODoH relay

#50

What would it take to get truly anonymous dns? I guess it’s not really possible no?

You wrap the DNS request in a different layer of encryption than the relay server, so the relay server only knows you tried to resolve something , and the DNS server only knows someone tried to resolve a particular domain. That's how ODoH works. To make it harder for parties to collude, you need additional encrypted hops, the way Tor does. ODoH doesn't do that, unless you're routing ODoH through Tor of course. You wo…

[flagged]
Post reply on HN