Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Shutting down our public encrypted DNS

mullvad.net

Post reply on HN
Print view View original

261–270 of 271 posts

Re: Shutting down our public encrypted DNS

#261

Post by iamnothere »

jcgl wrote: post #260
iamnothere wrote: post #259

Earlier quoted context omitted.

A “virtual” ISP may not have my personal details, especially if I am careful about it. I agree that it’s a tradeoff. Some people may live under regimes where big DNS servers are blocked or under legal orders, or they may have concerns about imminent DNS censorship or logging orders.

- Personal details isn't the point (and while a VPN service may have those, a big DNS resolver certainly doesn't)--the point is that correlating DNS traffic with your source/home IP address is likely easier with a big DNS resolver. In any case, I don't see how the VPN approach is superior here. - People may also live under regimes where VPN providers are blocked. Unless there's some order of magnitude more limitation…

Anonymizing VPNs, especially multi-hop ones, and Tor in particular makes correlation much more difficult. Mullvad paid in crypto or cash is a very good option.

I agree about blocked VPN providers, but in the real world it’s usually possible to get around those blocks, even in places like China where there are sophisticated national firewalls.

Re: Shutting down our public encrypted DNS

#262

Post by tptacek »

zamadatix wrote: post #119
justsomehnguy wrote: post #79

Earlier quoted context omitted.

You are rely here on the assumption what your resolver already knows what the zone is DNSSEC signed. If your forwarder or resolver strips that information?..

At a high level, one of 3 things happens: 1. The forwarder gets a response claiming the record is supposed to be DNNSEC signed from the parent (recursively traversing from the root). The forwarder checks the signature of this claim. If the signature is valid, the forwarder continues on to validate the signature of the record and checks its validity to know if the info was secure. If the signature is invalid, the forw…

You have two recursers (or recurser-capable systems, in the case of a forwarder), an upstream that you tentatively trust and a downstream one you trust completely (because end systems use stub resolvers and have to blindly trust a recursive resolver somewhere).

Can you be more specific about how, using current DNS software, that downstream resolver can reliably detect whether a zone is DNSSEC signed? The upstream recurser can erase every DNSSEC record in the tree if it wants. What does the downstream recurser do short of jettisoning the upstream and doing all its own recursive lookups?

Re: Shutting down our public encrypted DNS

#263

Post by hulitu »

morserer wrote: post #70
autoexec wrote: post #25

Earlier quoted context omitted.

I don't think there's any company with useful information on the American public that isn't being forced to regularly hand over that data. That's probably been true to some extent for a long time (see Room 641A) but it's certainly gotten worse. At this point you can't check out a book from the library without the feds demanding that your librarian turn over a list of everything you've ever read, or rent a hotel room…

For clarification, this is completely true of the US, without needing to speculate, thanks to a combination of FISA 702, the ECPA, CALEA, EO 12333, and the CLOUD act. It all has legal footing in the States. However, it's not at all the reality of a vast swath of other countries (or, at least, not yet; see Chat Control v2). The US is particularly foul (and effective) when it comes to this practice, but anything outsid…

> However, it's not at all the reality of a vast swath of other countries

Citation needed. At least in DE it is also true.

Re: Shutting down our public encrypted DNS

#264

Post by jcgl »

iamnothere wrote: post #261
jcgl wrote: post #260

Earlier quoted context omitted.

- Personal details isn't the point (and while a VPN service may have those, a big DNS resolver certainly doesn't)--the point is that correlating DNS traffic with your source/home IP address is likely easier with a big DNS resolver. In any case, I don't see how the VPN approach is superior here. - People may also live under regimes where VPN providers are blocked. Unless there's some order of magnitude more limitation…

Anonymizing VPNs, especially multi-hop ones, and Tor in particular makes correlation much more difficult. Mullvad paid in crypto or cash is a very good option. I agree about blocked VPN providers, but in the real world it’s usually possible to get around those blocks, even in places like China where there are sophisticated national firewalls.

These things you suggest incur significant latency. Also, can you simply pipe DNS over Tor? I don't see how, since Tor is TCP-only. I suppose DoT or DoH could potentially work, but not all authoritative servers may support those protocols. The TCP handshake will also add further latency.

Furthermore, even once you layer all that tunneling on top, it's still unclear how doing recursive resolution from your end of the tunnel is better than going through one of the big resolvers. The privacy benefits seem marginal at best. Overall, I don't think you have convinced me in the slightest of your original point that "really anyone who cares about bypassing national blocking orders should run a local caching recursive resolver."

Re: Shutting down our public encrypted DNS

#265

Post by hulitu »

tancop wrote: post #40
greyface- wrote: post #36

Earlier quoted context omitted.

Adversaries don't always ask nicely. Sometimes they break in and silently take the data. These services centralize traffic flows and make it so that an adversary only needs to tap one or two circuits to get a full picture for all users of a service.

CIA is not stupid enough to break into a guarded data center in Switzerland or one of the less America friendly EU countries. They tell the NSA to look for security holes and spread narratives that only criminals use VPN hoping that a politician will notice and try to ban them, like what's happening in the UK. Big tech services are less private than you think but almost every provider who cares about privacy is safer…

> CIA is not stupid enough to break into a guarded data center in Switzerland

They don't need to break in guarded data centers. See Crypto AG

> or one of the less America friendly EU countries.

Besides Spain, there is no such country in EU. And even Spain might change its mind.

Re: Shutting down our public encrypted DNS

#266

Post by iamnothere »

jcgl wrote: post #264
iamnothere wrote: post #261

Earlier quoted context omitted.

Anonymizing VPNs, especially multi-hop ones, and Tor in particular makes correlation much more difficult. Mullvad paid in crypto or cash is a very good option. I agree about blocked VPN providers, but in the real world it’s usually possible to get around those blocks, even in places like China where there are sophisticated national firewalls.

These things you suggest incur significant latency. Also, can you simply pipe DNS over Tor? I don't see how, since Tor is TCP-only. I suppose DoT or DoH could potentially work, but not all authoritative servers may support those protocols. The TCP handshake will also add further latency. Furthermore, even once you layer all that tunneling on top, it's still unclear how doing recursive resolution from your end of the…

If your centralized DNS server receives a blocking order, what are you doing to do? You’ll have to do something. Give me another alternative then. In the current geopolitical environment, this is not idle speculation, it’s a real threat.

Latency is a tradeoff, I mentioned there are tradeoffs. For an individual or home network, the latency should not be a problem especially with caching.

As for TCP/UDP, current RFCs say that DNS servers must accept TCP, but not all may follow the standard and some misconfigured firewalls may block it. But it doesn’t seem to be an issue when tunneling all traffic over Tor using something like Tails. So I don’t think this is really a problem.

Re: Shutting down our public encrypted DNS

#267

Post by jcgl »

iamnothere wrote: post #266
jcgl wrote: post #264

Earlier quoted context omitted.

These things you suggest incur significant latency. Also, can you simply pipe DNS over Tor? I don't see how, since Tor is TCP-only. I suppose DoT or DoH could potentially work, but not all authoritative servers may support those protocols. The TCP handshake will also add further latency. Furthermore, even once you layer all that tunneling on top, it's still unclear how doing recursive resolution from your end of the…

If your centralized DNS server receives a blocking order, what are you doing to do? You’ll have to do something. Give me another alternative then. In the current geopolitical environment, this is not idle speculation, it’s a real threat. Latency is a tradeoff, I mentioned there are tradeoffs. For an individual or home network, the latency should not be a problem especially with caching. As for TCP/UDP, current RFCs s…

Same thing as if something equivalent happens to your VPN service I guess? Switch to another one.

Oh yeah crap, you're right about DNS over regular TCP. I totally brainfarted on that.

Re: Shutting down our public encrypted DNS

#268

Post by hulitu »

PinkSheep wrote: post #189
pocksuppet wrote: post #118

Earlier quoted context omitted.

Are you sure? Someone broke into a Hetzner data center and a Linode one, physically intercepted the Ethernet cables for jabber.ru, and got certificates signed on their behalf. https://notes.valdikss.org.ru/jabber.ru-mitm/ https://news.ycombinator.com/item?id=37961166

dear sockpuppet =) I think the above commenter meant illegal physical access. The jabber.ru MitM situation was likely carried out by a cybercrime unit of the German police forces with a court order... and this is the adversary most people forget about. Lesson to learn: Let's Encrypt does not protect against MitM by a state-level actor, unless you take precautions. *let's assume network admins won't MitM your server f…

> Lesson to learn: Let's Encrypt does not protect against MitM

But S in https stands for secure, or ? /s

Re: Shutting down our public encrypted DNS

#269

Post by hulitu »

greyface- wrote: post #75
mrtesthah wrote: post #64

Earlier quoted context omitted.

The data would/should be encrypted; while the NSA did successfully tap Google's inter-datacenter traffic before the Snowden leaks, since then it is encrypted, too. Hopefully other providers won't fall for that trick anymore, either.

IIRC, Google addressed the incident you're referring to by adding E2E encryption to sensitive inter-DC RPC sessions, rather than by fully encrypting inter-DC traffic at the link level. It would be nice to be able to reasonably expect carrier/ISP backbones to be secure against this threat, but in our actual reality this seems like fantastical thinking.

> Google addressed the incident you're referring to by adding E2E encryption to sensitive inter-DC RPC sessions

And they don't provide the key to law enforcement because ... they care about your privacy. /s

Post reply on HN