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

#21

Post by kchamplewski » Sat, Sep 28, 2019, 6:18 PM UTC

tptacek wrote: post #19

bjoli wrote: post #16

Can anyone explain why DoH was invented? To me it seems like another one of the "let's solve this using web technologies!" Whereas DoT has a great ietf process behind it.

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…

The biggest complaint I have regarding DoH is that it's extremely painful to configure because every application does it individually.

If I could configure DoH at the system level, as I do normal DNS, I'd be perfectly happy. As it stands, DoH could trivially be co-opted by browser vendors to ignore system DNS settings, and even if it isn't, it still makes DNS configuration a worse experience.

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

#22

Post by shawnz » Sat, Sep 28, 2019, 6:19 PM UTC

> 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 Internet Ads using block lists.

This is a totally wrong usage of DNS and I wish we would focus more effort into making IP-based blocking easy and accessible rather than wasting time trying to make DNS fit this niche. DNS is not the right tool for this job and maintaining this functionality is not a valid reason to block progress on more private technologies like DoH. And it's totally possible to run a PiHole-style system using DoH anyway.

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

#23

Post by jchw » Sat, Sep 28, 2019, 6:21 PM UTC

Part of Paul Vixie’s argument is that DNS is part of the control plane, and that DoH will bypass security policy. Let’s at least address this with some skepticism.

1. Is security policy via DNS really a good way to go? There are other, imo more effective, ways of handling this. If your security policy can be defeated by using a DoH resolver, it’s evidently not very hard to bypass.

2. While this can be true, it’s not actually anything to do with the way DoH works. You could just as easily choose to only upgrade to DoH when the DNS provider of your choosing happens to support it.

3. Home internet is not new or uncommon. 76% of the US has internet access according to a cursory Google search. A vast, vast majority of these users are casual users. The control plane is not under their control necessarily. The control plane is not something that can just absolutely be trusted.

With much respect, I simply must disagree. The notion that DoH is dangerous feels like it comes from a dated view of internet security, and it only reflects the mode of rollout where application software indiscriminately uses a DoH server in place of the user’s default DNS server.

Further, this article has a lot of interesting claims. It claims that many websites are still not running over TLS even though it’s free. Of course, this is undoubtedly true and reflected in statistics. However, is it true in a realistic sense? How many non-HTTPS pages do you browse?

Thanks to Cloudflare and other actors, I suspect ESNI will have no trouble gaining meaningful marketshare. Not full proliferation. We don’t need full proliferation for it to be useful, though.

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

#24

Post by jdsnape » Sat, Sep 28, 2019, 6:21 PM UTC

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 can't see IP-based blocking helping here.

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

#25

Post by mlyle » Sat, Sep 28, 2019, 6:33 PM 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.

First, I know nothing about DoH, so take this with a grain of salt.

They should look up a canary domain that doesn't resolve from the roots, but local sites can configure to provide the address of a DoH resolver. Then you don't need to have a list of known DoH providers-- any site can install a DoH resolver and then add the canary domain to allow clients to upgrade.

It'd still be vulnerable to MITM attacks on initial connect, but at least the window for them is closed after the first resolution with this approach (better than normal DNS).

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

#26

Post by tptacek » Sat, Sep 28, 2019, 6:52 PM UTC

kchamplewski wrote: post #21

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…

The biggest complaint I have regarding DoH is that it's extremely painful to configure because every application does it individually. If I could configure DoH at the system level, as I do normal DNS, I'd be perfectly happy. As it stands, DoH could trivially be co-opted by browser vendors to ignore system DNS settings, and even if it isn't, it still makes DNS configuration a worse experience.

This seems a lot more like a complaint about your libc than about DoH. But the response to that complaint would likely be "give it time".

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

#27

Post by tptacek » Sat, Sep 28, 2019, 6:56 PM UTC

jchw wrote: post #23

Part of Paul Vixie’s argument is that DNS is part of the control plane, and that DoH will bypass security policy. Let’s at least address this with some skepticism. 1. Is security policy via DNS really a good way to go? There are other, imo more effective, ways of handling this. If your security policy can be defeated by using a DoH resolver, it’s evidently not very hard to bypass. 2. While this can be true, it’s not…

In reality what's happening is a conflict between the security goals of network operators and those of end-users. Vixie, who runs a company that provides security services based on passively observing DNS, believes DoH sacrifices the security of networks in favor of end-users, and he's right. But:

1. In most situations, the end-users are the ones that matter; the cart shouldn't drag the horse.

2. In situations where that doesn't hold, serious security teams already exert direct control (via MDM and endpoint security) over end-systems anyways; why should anybody give anything up to make things easier for enterprises who are just a bit concerned about security, but not enough to take responsibility for endpoint security?

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

#28

Post by jchw » Sat, Sep 28, 2019, 7:00 PM UTC

tptacek wrote: post #27

jchw wrote: post #23

Part of Paul Vixie’s argument is that DNS is part of the control plane, and that DoH will bypass security policy. Let’s at least address this with some skepticism. 1. Is security policy via DNS really a good way to go? There are other, imo more effective, ways of handling this. If your security policy can be defeated by using a DoH resolver, it’s evidently not very hard to bypass. 2. While this can be true, it’s not…

In reality what's happening is a conflict between the security goals of network operators and those of end-users. Vixie, who runs a company that provides security services based on passively observing DNS, believes DoH sacrifices the security of networks in favor of end-users, and he's right. But: 1. In most situations, the end-users are the ones that matter; the cart shouldn't drag the horse. 2. In situations where…

>DoH sacrifices the security of networks in favor of end-users

I agree, if you are considering the approach of just using an arbitrary DoH server. But I think it would be nice if people would at least acknowledge that this is not a fault of DoH. One could envision a future where local DNS servers could support DoH. I don't know how far away from reality this is, though.

If this is somehow a fault of DoH, I apologize for my misunderstanding. I admittedly haven't read the full standard.

>serious security teams already exert direct control (via MDM and endpoint security) over end-systems anyways

Thank you, this is precisely what I was thinking.

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

#29

Post by tptacek » Sat, Sep 28, 2019, 7:03 PM UTC

jchw wrote: post #28

tptacek wrote: post #27

Earlier quoted context omitted.

In reality what's happening is a conflict between the security goals of network operators and those of end-users. Vixie, who runs a company that provides security services based on passively observing DNS, believes DoH sacrifices the security of networks in favor of end-users, and he's right. But: 1. In most situations, the end-users are the ones that matter; the cart shouldn't drag the horse. 2. In situations where…

>DoH sacrifices the security of networks in favor of end-users I agree, if you are considering the approach of just using an arbitrary DoH server. But I think it would be nice if people would at least acknowledge that this is not a fault of DoH. One could envision a future where local DNS servers could support DoH. I don't know how far away from reality this is, though. If this is somehow a fault of DoH, I apologize…

It's not at all a fault of DoH, since preventing "control plane operators" from coercing end-users into giving up their privacy is DoH's primary goal.

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

#30

Post by zrm » Sat, Sep 28, 2019, 7:07 PM UTC

jchw wrote: post #23

Part of Paul Vixie’s argument is that DNS is part of the control plane, and that DoH will bypass security policy. Let’s at least address this with some skepticism. 1. Is security policy via DNS really a good way to go? There are other, imo more effective, ways of handling this. If your security policy can be defeated by using a DoH resolver, it’s evidently not very hard to bypass. 2. While this can be true, it’s not…

> Is security policy via DNS really a good way to go? There are other, imo more effective, ways of handling this. If your security policy can be defeated by using a DoH resolver, it’s evidently not very hard to bypass.

That's assuming the clients and the network are adversarial to each other. Consider that the local DNS resolver may be blocking domains associated with malware or ads, which the client wants for it to do, and then changing the default DNS from the one configured via DHCP results in clients getting malware and ads they didn't want.

> While this can be true, it’s not actually anything to do with the way DoH works. You could just as easily choose to only upgrade to DoH when the DNS provider of your choosing happens to support it.

The major criticism of DoH is Firefox enabling it by default and overriding the existing system DNS configuration, requiring manual reconfiguration of arbitrarily many client devices to change it back to the way it was. There can obviously be no legitimate objection to it if it is disabled by default and only used when explicitly enabled by the user.

> Home internet is not new or uncommon. 76% of the US has internet access according to a cursory Google search. A vast, vast majority of these users are casual users. The control plane is not under their control necessarily. The control plane is not something that can just absolutely be trusted.

This is a great argument for making DoH/DoT/DNSCurve/etc. the default configuration for the builtin resolver in home internet routers. Which thereby solves the problem without introducing a new one where if you want to change the default it requires reconfiguring arbitrarily many separate applications on every individual client device, because in that case you can still configure the DNS for the local network in one location.