Analyzing DNS-over-HTTPS and DNS-over-TLS Privacy and Security Claims • Hacker News Board

Re: Analyzing DNS-over-HTTPS and DNS-over-TLS Privacy and Security Claims

#51

Post by tptacek » Sat, Sep 28, 2019, 11:21 PM UTC

pdkl95 wrote: post #47

tptacek wrote: post #19

Earlier quoted context omitted.

Two primary use cases were considered during this protocol's development. These use cases are preventing on-path devices from interfering with DNS operations, and also allowing web applications to access DNS information via existing browser APIs in a safe way consistent with Cross Origin Resource Sharing (CORS). Virtually all the opposition to DoH is rooted in two complaints: 1. It centralizes DNS at Cloudflare (obvi…

> you can point DoH elsewhere That only fixes the "Cloudflare" problem. It still centralize all DNS traffic onto a single service. I cannot configure Firefox to send packets only to the (hypothetically DoH capable) delegated nameserver(s) for each domain. When you run your own recursive resolver (which is easy), only the lookup of the NS delegations needs to use a centralized service. This is relatively infrequent (N…

Running your own recursive resolver on your own machine doesn't address DNS privacy; in fact, it does the opposite, making your DNS lookups even more attributable. Of course, you can run your own resolver on a network somewhere else, and then DoH to it, but then you're just making my point for me.

Re: Analyzing DNS-over-HTTPS and DNS-over-TLS Privacy and Security Claims

#52

Post by alibert » Sat, Sep 28, 2019, 11:22 PM UTC

My fear is that platforms start using DoH, bypassing local dns privacy resolver such as pihole, for tracking purpose. I have a nVidia Shield and I can see how many requests to tracking domains it does and if nVidia or Google uses DoH, I will not be able to block those requests.

Re: Analyzing DNS-over-HTTPS and DNS-over-TLS Privacy and Security Claims

#53

Post by collsni » Sat, Sep 28, 2019, 11:38 PM UTC

DOH has the possibility to leverage the wrong parties against encryption. There needs to be a barrier of control.

Re: Analyzing DNS-over-HTTPS and DNS-over-TLS Privacy and Security Claims

#54

Post by the8472 » Sun, Sep 29, 2019, 12:04 AM UTC

icebraining wrote: post #13

the8472 wrote: post #10

Earlier quoted context omitted.

How would chrome know whether getaddrinfo() uses DoH to resolve a host?

Anyone can link to their own getaddrinfo(), including an internal function, they don't have to use one from whichever libc happens to be laying around on the system. In theirs, they read the DNS servers from the OS (like the original), and then if it's part of a list of known DoH providers, they try to connect over DoH before falling back to regular DNS queries.

That would mean bypassing OS configuration, including other naming sources then DNS.

Re: Analyzing DNS-over-HTTPS and DNS-over-TLS Privacy and Security Claims

#55

Post by icebraining » Sun, Sep 29, 2019, 12:56 AM UTC

the8472 wrote: post #54

icebraining wrote: post #13

Earlier quoted context omitted.

Anyone can link to their own getaddrinfo(), including an internal function, they don't have to use one from whichever libc happens to be laying around on the system. In theirs, they read the DNS servers from the OS (like the original), and then if it's part of a list of known DoH providers, they try to connect over DoH before falling back to regular DNS queries.

That would mean bypassing OS configuration, including other naming sources then DNS.

Yes, and if you search for "Chrome DNS client", people have reported problems related to that.

Re: Analyzing DNS-over-HTTPS and DNS-over-TLS Privacy and Security Claims

#56

Post by pdkl95 » Sun, Sep 29, 2019, 1:31 AM UTC

tptacek wrote: post #51

pdkl95 wrote: post #47

Earlier quoted context omitted.

> you can point DoH elsewhere That only fixes the "Cloudflare" problem. It still centralize all DNS traffic onto a single service. I cannot configure Firefox to send packets only to the (hypothetically DoH capable) delegated nameserver(s) for each domain. When you run your own recursive resolver (which is easy), only the lookup of the NS delegations needs to use a centralized service. This is relatively infrequent (N…

Running your own recursive resolver on your own machine doesn't address DNS privacy; in fact, it does the opposite, making your DNS lookups even more attributable . Of course, you can run your own resolver on a network somewhere else, and then DoH to it, but then you're just making my point for me.

> making your DNS lookups even more attributable

That's missing the point. I don't care what a nameserver learns from my DNS request when I'm almost always going to follow that request by opening s socket to the referenced server. The delegated nameserver and the referenced (e.g. HTTP{,S}) server are controlled by the same entity, which is compartmentalized from other unrelated DNS requests when you perform the recursive resolution locally.

It seems like you're only considering privacy at the protocol level. While that's important, it can eventually be fixed with improved protocols. I'm far more concerned about de facto standardizing on requiring a centralized service that necessarily has access to the plaintext DNS traffic. The only way to prevent logging of the user's entire internet pattern-of-life is to not give the entire pattern to a single entity.

To be clear: we should be updating all plaintext protocols with encryption/etc. Both DoT and DoH can help achieve that goal. Some sort of encrypted protocol is needed even when running a recursive resolver (such as DoT). It would also be great if popular OS had built-in support for running a local recursive resolver, OS-level support for DoH/DoT, and other advanced features.

Re: Analyzing DNS-over-HTTPS and DNS-over-TLS Privacy and Security Claims

#57

Post by comex » Sun, Sep 29, 2019, 3:44 AM UTC

jdsnape wrote: post #24

shawnz wrote: post #22

> DNS is one important control planes in a network. It essentially allows network administrators to block content based on domain names making it quite useful tool in the arsenal. It is being widely used to provide content filtering services, parental controls, and to block known malware command and control. Its so popular that a lot of people install a locally running DNS server on their home networks to block Inter…

I'm not convinced IP-based blocking can be more effective than DNS blocking. Very often many different sites are hosted on one IP address (e.g. a CDN in the 'worst' case), and IP blocking would mean lots of things become inaccessible. Users access services by DNS name, so if you want to control access it has to be at that level. Whether DNS can be effectively blocked while maintaining privacy is another issue, but I…

In my opinion, both DNS- and IP-based blocking are a hack because they fundamentally have to work based on limited information. After all, ad services could pretty easily start doing any of the following:

- proxying ad requests through the server of the website you're visiting;

- accessing ads by IP address directly; or

- using randomly generated domain names.

With a browser-based ad blocker, those measures would still be an obstacle, but at least you'd have a chance - you could switch to more heuristic ways of detecting ads based on, say, the scripts involved, or the content of the media being downloaded, or its size and placement on the page. None of that information is available to network-based blockers, at least not when HTTPS is in use.

Admittedly, those things probably won't happen anytime soon, at least not for regular website ads. (Though as one example, Twitch has already started using fairly sophisticated measures to bypass ad blockers for their video ads...) But I'm an idealist, and I like to fight on favorable territory. When it comes to cat and mouse games, I don't want to be the mouse.

Re: Analyzing DNS-over-HTTPS and DNS-over-TLS Privacy and Security Claims

#58

Post by tptacek » Sun, Sep 29, 2019, 3:52 AM UTC

pdkl95 wrote: post #56

tptacek wrote: post #51

Earlier quoted context omitted.

Running your own recursive resolver on your own machine doesn't address DNS privacy; in fact, it does the opposite, making your DNS lookups even more attributable . Of course, you can run your own resolver on a network somewhere else, and then DoH to it, but then you're just making my point for me.

> making your DNS lookups even more attributable That's missing the point. I don't care what a nameserver learns from my DNS request when I'm almost always going to follow that request by opening s socket to the referenced server. The delegated nameserver and the referenced (e.g. HTTP{,S}) server are controlled by the same entity, which is compartmentalized from other unrelated DNS requests when you perform the recur…

DoH is the improved protocol. There's nothing "centralized" about it; you can run a DoH cache server anywhere you want.

The only reason anyone advocates DoT is because network operators can block it, forcing people to use plaintext DNS. Somehow, the meme has been created that DoT is somehow better or more privacy-respecting than DoH, but that's obviously false.

Re: Analyzing DNS-over-HTTPS and DNS-over-TLS Privacy and Security Claims

#59

Post by zrm » Sun, Sep 29, 2019, 8:48 PM UTC

tptacek wrote: post #50

zrm wrote: post #49

Earlier quoted context omitted.

Adversarial networks are not the common case. On the majority of networks you can send a plaintext UDP DNS query to 8.8.8.8 or 1.1.1.1 and nothing will actually interfere with it in practice. Adversarial networks exist , which is why something like DoH or DNSCurve should be used in favor of unauthenticated DNS over the internet, but the real issue here is independent of which DNS protocol is used -- it's how the recu…

Your threat model isn't the set of actors currently attacking you , but rather those actors who can and might attack you in the future. Your ISP is certainly adversarial in any sane threat model.

Aren't you the one usually telling everyone that DNSSEC is useless even though it solves the same problem, e.g. because the server can be verified with TLS instead? If the DNS attack is nothing more than a denial of service then it seems completely reasonable to wait until the attack is actually observed before applying a mitigation (third party DNS) that can have problematic side effects. Especially when the mitigation can be made as simple as a single checkbox in the browser.

And what makes Cloudflare any more trustworthy than the average ISP? Isn't that just switching the user's resolver from the network they explicitly chose to connect to, to a centralized third party that they didn't?

Re: Analyzing DNS-over-HTTPS and DNS-over-TLS Privacy and Security Claims

#60

Post by tptacek » Sun, Sep 29, 2019, 9:20 PM UTC

zrm wrote: post #59

tptacek wrote: post #50

Earlier quoted context omitted.

Your threat model isn't the set of actors currently attacking you , but rather those actors who can and might attack you in the future. Your ISP is certainly adversarial in any sane threat model.

Aren't you the one usually telling everyone that DNSSEC is useless even though it solves the same problem, e.g. because the server can be verified with TLS instead? If the DNS attack is nothing more than a denial of service then it seems completely reasonable to wait until the attack is actually observed before applying a mitigation (third party DNS) that can have problematic side effects. Especially when the mitigat…

DNSSEC doesn't solve any practical problem, but does have the effect of escrowing TLS keys to world governments. DoH solves an immediate problem, which is that ISPs (and other entities) passively monitor DNS traffic to collect intelligence on network users. DNSSEC does nothing about this problem.

You don't have to use Cloud Flare for DoH, and I wouldn't.