Hacker News Reader

Comment by tptacek | Hacker News Reader

Yes. If you're concerned that your third-party resolver is monetizing or otherwise monitoring your DNS, you can run your own DoH recursor, semi-anonymously, from a public cloud account. In the long run, presumably trustworthy organizations will stand up DoH resolvers that people can trust.

I preemptively agree that Cloud Flare is not one of those organizations.

It is unclear to me why any home user would deliberately opt for DoT. DoH and DoT solve the exact same problem, and DoH is by design harder to filter.

View on HN

> It is unclear to me why any home user would deliberately opt for DoT. DoH and DoT solve the exact same problem, and DoH is by design harder to filter.

Perhaps a parent wants something that's easier to filter.

Paul Vixie has said a lot on this topic.

Yes; Paul Vixie is to DoH what I am to DNSSEC, and his consistent case is "DoH is bad because it's hard for network operators to turn it off for users". To me, that's a ringing endorsement.

> To me, that's a ringing endorsement.

And to me, who works in IT, it's a bloody annoying.

We've already implemented the use-application-dns.net NXDOMAIN canary at work because after some testing Firefox breaks a bunch of apps because of split-horizon DNS.

There's already (at least) two malware that's using DoH to get around network monitoring:

* https://www.zdnet.com/article/first-ever-malware-strain-spot...

* https://www.zdnet.com/article/psixbot-malware-upgraded-with-...

If the host is compromised we can no longer trust end-point monitoring, and with DoH/ESNI we lose network monitoring. Awesome. Great work.

I absolutely understand why it's bloody annoying for network operators. What I don't understand is why any home user should trade even the tiniest iota of their privacy to make your life any easier. You get paid to deal with these problems.

In certain situations, even home users are in the same position as network operators. The processes running on their machines will use exactly these same mechanisms to escape the user control. The last few years have shown, that big brand names are not to be trusted, and their interests, as implemented in their software, are not aligned with user interests. In a way, we are getting back full-circle to Stallman.

DoH+ESNI will make it even harder.

I don't understand whether you're saying that DoH+ESNI will make it harder for malicious network operators to compromise user privacy (clearly true) or whether DoH+ESNI will make it harder for home users to run their networks as if they were enterprise networks.

It would be a genuinely weird new take to argue that encrypted SNI was somehow harmful to privacy.

What is privacy? The same way the home user can get privacy from the network operator, can malware get its privacy from the home user.

This is amplified by moving DNS resolution into applications, Mozilla style. Now even the operating system or local firewall applications (Little Snitch, etc) can't know, where the processes are connecting.

Again, the application vendors can have objectives that are not aligned with the users. It is a mistake to conflate the home users with random applications running on their computers.

This argument doesn't make any sense. TLS SNI hostnames should remain unencrypted to help user privacy?

No.

The argument is, that a random process should not be a world into itself; there should be a way to check on what it is doing. It does not have to be network based, it can be done by another process on the local machine. Things like DNS should be done by the OS, with hooks for the monitoring. It should be not be done by the application, with zero transparency to the owner. The system resolver, on the other hand, can use DoH/DoT/ESNI/whatever.

Giving random processes unlimited, uncontrolled and uncontrollable access to Internet is disaster waiting to happen. Quite similar to what happened to applications on Android.

What does the system resolver have to do with encrypting TLS SNI?

With the privacy.

I don't know, whether I'm expressing badly due to English not being my native language, or where is the problem in understanding. I hope that you are not just misunderstanding intentionally.

So once again: The combination of ESNI and DNS resolving inside applications (and not OS, not checked by some user agent) provides privacy to application, not users. That application might or might not have its objectives aligned with the users; more often than not, it will focus on interests of its vendor instead. So conflating privacy for application with privacy for user is mistake.

By applications using custom DNS+ESNI, the user loses control over who the application communicates with, he just sees that it can send and receive blobs. What it is sending out, to whom, is and will be unknown. That is the negative wrt user's privacy, compared to which the current Android ecosystem is squeaky clean.

> It would be a genuinely weird new take to argue that encrypted SNI was somehow harmful to privacy.

As a 'network operator' at work and home, it is my responsibility to keep my network clean. Both for my own sake and for the sake of the greater Internet (is malware being spread from my network?).

End-host security is used to make sure that connected systems are clean. But if the end-host is compromised, then that may now become useless. So a second level of security is network monitoring.

However, how can I be responsible network operator if I have no visibility into my own infrastructure? DoH by-passing local DNS, and ESNI cloaking the destinations, make it impossible to see who is doing what. At least with Do53 (and DoT) I can control lookups (possibly to C&C servers).

If you were counting on DNS and SNI monitoring to detect compromised endpoints, you’ve lost anyways, because malware can chose its own dns resolution method and avoid SNI regardless of what the OS or Firefox are set up to do.

Even better, Malware can (popular malware doesn't so far as I can see today, but could if other methods stopped working) straight up lie in SNI and in the old TLS 1.2 plaintext Certificate message, and produce plausible yet entirely misleading results in your inspection apparatus.

A real client expects the encrypted parts that follow Certificate to match up and should abort if they don't, but malware is under no obligation to do that, and a 3rd party which can't decrypt the rest of the handshake won't know e.g.

Malware client: SNI for bigbank.example (knowing bigbank will have been excluded from snooping rules at the target)

Malware C&C server: 100% Legitimate Certificate copied from bigbank.example

Malware client: Cool, let's continue with encrypted setup (ignores the pretence that this is bigbank.example and now communicates with the C&C server undetected and encrypted knowing the logs will just show "bigbank.example")

"Security" products can't protect against this without snooping each and every single transaction, but many will be deployed by ignorant/ well-meaning people who don't understand how this works and thus that the products can't actually do what they appear to offer to do.

> ... because malware can chose its own dns resolution method ...

Except before DoH I could monitor DNS: with plain DNS ("Do53") it is completely visible, and with DoT it is on a different port so it can be filtered.

Which is Paul Vixie's point: DoH takes control away from network owners, like me and my home Asus, and me and work.

Yes, but the malware isn't required to use port 53 or "plain DNS" at all...

Regardless of what the OS or Firefox or whatever existing app uses, a malicious binary could just use DoH, or just make an HTTP request directly to an IP, or skip HTTP/DNS entirely and fling data out over UDP to an external IP.

Put another way: if your issue is that DoH removes your ability to catch DNS requests from malware, your issue isn't with users enabling DoH, or with app devs defaulting their apps to DoH, your issue is with the concept of non-DNS network protocols. Even if DoH was never standardized, an attacker isn't required to make lookups on port 53 as you desire.

> I preemptively agree that Cloud Flare is not one of those organizations.

Would you please elaborate on your distrust of Cloudflare? I’m not looking to call you out. Quite the opposite, I appreciate your candor. I just feel like I’m missing some context.

I'm not comfortable getting into it here. Just suffice it to say that my support for DoH has absolutely nothing to do with Cloud Flare's support for it.

We all should be worried about loss of privacy, but we can't all run our own resolvers on the cloud.

The choice of DoT vs DoH will mostly be about what is supported by one's choice of resolver. Of course, choosing DoH first will narrow the choice of resolvers.

Then there's captive portal situations.

This is a false controversy. The people that "can't" run their own resolvers are, overwhelmingly, using their ISP's resolvers. At least in the US, all of those ISPs are actively attacking their users. Users are better off using practically any other mainstream centralized DNS provider than their ISP default.

But this isn't a stable equilibrium; as I said, it seems clear that privacy-minded organizations will eventually stand up their own trustworthy DoH resolvers.

DoH makes things somewhat better today for all users, and much better for power users. In the long term, it's easy to see how DoH makes things much better for everybody.

Running one's own recursor using DNSSEC via an ISP's resolver (for the privacy benefit relative to authoritatives) would take care of active attacks by ISPs on their users. Windows and Linux could do this you know, but security would be enhanced only relative to sites that use DNSSEC.

But I don't disagree that DoH is better.

I do hope that in the long run ISPs become less toxic.

Running one's own resolver with DNSSEC would do absolutely nothing about the ISP threat, since DNSSEC is a cleartext signing-only protocol. Since the overwhelming majority of zones aren't signed, it won't even protect you from the garish NXDOMAIN landing page attack.

I was referring to active attacks. I don't consider an ISP or a public resolver operator to be particularly different w.r.t. passive attacks: both get to do it, and both do do it.

Do you think quad9[0] is a trustworthy organization?

[0]: https://www.quad9.net

Tricky question. I'm the chairman of Quad9's board of directors. So _I_ trust the organization. But I'd urge everyone else not to trust _any_ organization, but instead to do as much to protect yourself as possible, using an external recursive resolver only when you need to.

That means running your own caching resolver, with a local copy of the root zone and QNAME minimization enabled, and then using DNS-over-TLS to forward the minimum necessary query onward.

The next question then becomes whether to perform recursion yourself (by talking directly with authoritative nameservers) or to have Quad9 or another recursive server perform the recursion for you. Authoritative nameservers don't yet support transport encryption, though we're working very hard to support it on the 500 TLDs PCH is authoritative for, and Verisign is working very hard to support it on .COM and .NET. So that means that your traffic is subject to interception, and essentially all authoritative servers either log queries or have people logging queries off the wire in front of them. And if you're handling your own recursion, everything you don't have cached crosses the wire, and none of it is blended together with anyone else's traffic.

To make the decision as to whether it's better to trust a recursive or send queries directly, knowing something about the practices and purpose of the recursive is necessary. Quad9 is the only major recursive that's a public-benefit not-for-profit. There are other small ones which are not-for-profits (like the Taiwanese 101.101.101.101, operated by TWNIC), but all of the others that come near Quad9's scale or traffic are for-profit, operated by companies that monetize data. Quad9 and Cisco's commercial Umbrella service are the only two which are GDPR-compliant and thus legal to provide to European citizens.

Quad9 exists solely so that bad choices won't be the only choices.

              -Bill Woodcock
               Chairman of the Board of Directors
               Quad9

Reply on news.ycombinator.com