6 ms·

It’s a double edged sword. DoH will enable unblock-able ads.

by donmcronald 7y ago

dredmorbius 7y ago
DNSMasq, the resolver used by many adblock tools, supports DNS-over-HTTPS.
- throw0101a 7y ago
  This assumes the web browser talks to your DNSmasq server. Currently Mozilla is making a straight run to Cloudflare.
  - dredmorbius 7y ago
    If your (on-LAN or otherwise under-your-control) DNS server talks DNS-over-HTTPS, Mozilla can just talk directly to it. That's the point. The browser-specific option can be used where that's not viable or reliable (mobile devices, third-party networks). And devices are handed DNS servers (with the option to opt out) via DHCP when they connect to the LAN.
    - throw0101a 7y ago
      Okay, and if malware uses DoH to figure out how to connect to its C&C server, how do I stop that DoH request (given it looks like any other HTTPS request)? If Cloudflare starts serving DNS traffic from HTTPS on its CDN, the malware can use Cloudflare for DNS. Am I supposed to block all of Cloudflare's IPs because they can be used to circumvent DNS query monitoring?
      - ubercow13 7y ago
        Does this really matter? I am sure there are other ways malware could work around DNS blocking if it was motivated to
        throw0101a 7y ago
        It depends on the malware. If it's self-contained and only goes around encrypting things and then prints a message to send money to a pre-defined particular Bit Coin address, then it won't matter. If it needs to phone home or otherwise contact an outside address (excluding hard-coded IP addresses), then presumably it needs it needs to do a DNS look-up at some point. Many botnets use pseudo-random DNS domains, and when the generation algorithm was figured out, people were able to get control of it: * https://en.wikipedia.org/wiki/Botnet#Domains https://en.wikipedia.org/wiki/Botnet#Domains * https://en.wikipedia.org/wiki/Fast_flux https://en.wikipedia.org/wiki/Fast_flux
      - dredmorbius 7y ago
        That's a separate threat model. DoH addresses surveillance, censorship, and injection by ISPs. One DNSmasq already addresses in part through various asblock and malware-blocking DNS blacklists. I'm using one such that updates hourly or better. Requests to or for specific domains my be blocked (and are). Keep in mind that by using DNSmasq at a centralised LAN server, you now have a single point of control to defend against such threats, rather than relying on multiple device- and application-specific points of control. Though software (such as browsers) offerring its own defences against such threats is in no way hindered. You can further, and more appropriately IMO, defend against such threats at the firewall level, by blocking network space (rather than domains) and ports associated with malware. At the OS level, firewalls such as Little Snitch monitor and block traffic at the application / process and user level, and may detect, alert on, and/or block such malware.
        throw0101a 7y ago
        > * That's a separate threat model. DoH addresses surveillance, censorship, and injection by ISPs.* As does DNS-over-TLS. Though since it has an official IANA port, this can be blocked. > You can further, and more appropriately IMO, defend against such threats at the firewall level, by blocking network space (rather than domains) and ports associated with malware. And if malware leverages Cloudflare, am I supposed to block that? The ports associated with malware may be HTTPS.
        dredmorbius 7y ago
        How does DoH make any of this worse than straight UDP/53 DNS? You seem to be manufacturing a hypothetical threat that isn't actually impacted by DoH, to no clear end. Malware already exploits specific IP spaces (DUL, datacentres, AWS), and ports (20, 22, 25, 53, 80, 443, ...), as well as vectors such as adtech networks, IFRAME, and XHR. Those are blocked as best as possible, leveraging numerous signature, to varying degrees of effectiveness. Methods are not perfect. But if they on net reduce or manage risks more effectively, they're a net win. Again, DoH, either in the browser or at the LAN level, addresses a specific set of known risks. And I'm not seeing the caveats you're suggesting as either more severe or non-mitigable.
realshowbiz 7y ago
How?
- Skunkleton 7y ago
  Dns blacklisting of ad domains is a common technique.
  - staticassertion 7y ago
    That hardly makes ads "unblockable".
    - squiggleblaz 7y ago
      At the moment you can make a tv that resolves dns using 8.8.8.8 and looks at fancy.ads to display an add in the tv guide/web browser/youtube app/whatever. But I can make my router direct any dns request back to itself and filter fancy.ads so that it never resolves to anything useful. DNS over HTTPS means that you can make a tv that resolves dns using https://8.8.8.8 https://8.8.8.8 and looks at fancy.ads. But I can't mitm it because I don't have a suitable trusted certificate to respond to that request. So either the request to fancy.ads gets dropped and the request to online.movies.example.com gets dropped so I can't use my smart tv for its intended purpose. Or both get through. Obviously things are different if the service uses standard OS level configuration so I can tell it to resolve dns using https://my.adblocked.dns https://my.adblocked.dns or /etc/hosts. But nothing obliges any particular system to do that. If my logic is faulty, please, do inform.
      - uponcoffee 7y ago
        The solution is to do as most goverments do [0]: sniff the SNI header during TLS handshakes and drop the connection if the domain matches your blocklist(s)//regex filters. [0] https://signal.org/blog/looking-back-on-the-front/ https://signal.org/blog/looking-back-on-the-front/
      - NegativeLatency 7y ago
kibwen 7y ago
It would only be a difficulty for intercepting devices like PiHoles (and I don't think it's an insurmountable difficulty either, if you control both the Pi and the computer). It wouldn't affect browser-based adblockers, which is how the majority of adblocking is already done, because browsers already have access to the unencrypted request.
- 15characterslon 7y ago
  That would be my point too. DNS-based content blocking is very ineffective and can be outsmarted very easily. DNS filters might be very easy to set up but if they become more major they can be outsmarted very easily - what if Google starts serving ads from www.google.com, would you block that domain name too? Browser extensions can block content far more precisely. And smart TVs and such stuff could easily switch resolvers and just not use your Pihole's DNS resolver - that would work even without DoH as long as you don't intercept traffic on your router. E.g. Fire TV already adds Google DNS as an additional DNS server (you can't change that). Chromecast only uses Google DNS (AFAIK you can't change that either). I guess the only viable option here is just not to buy those products.
  - tty2300 7y ago
    Or just intercept and redirect requests to googles DNS.

It’s a double edged sword. DoH will enable unblock-able ads.

dredmorbius 7y ago

DNSMasq, the resolver used by many adblock tools, supports DNS-over-HTTPS.

throw0101a 7y ago
This assumes the web browser talks to your DNSmasq server. Currently Mozilla is making a straight run to Cloudflare.
- dredmorbius 7y ago
  If your (on-LAN or otherwise under-your-control) DNS server talks DNS-over-HTTPS, Mozilla can just talk directly to it. That's the point. The browser-specific option can be used where that's not viable or reliable (mobile devices, third-party networks). And devices are handed DNS servers (with the option to opt out) via DHCP when they connect to the LAN.
  - throw0101a 7y ago
    Okay, and if malware uses DoH to figure out how to connect to its C&C server, how do I stop that DoH request (given it looks like any other HTTPS request)? If Cloudflare starts serving DNS traffic from HTTPS on its CDN, the malware can use Cloudflare for DNS. Am I supposed to block all of Cloudflare's IPs because they can be used to circumvent DNS query monitoring?
    - ubercow13 7y ago
      Does this really matter? I am sure there are other ways malware could work around DNS blocking if it was motivated to
      - throw0101a 7y ago
        It depends on the malware. If it's self-contained and only goes around encrypting things and then prints a message to send money to a pre-defined particular Bit Coin address, then it won't matter. If it needs to phone home or otherwise contact an outside address (excluding hard-coded IP addresses), then presumably it needs it needs to do a DNS look-up at some point. Many botnets use pseudo-random DNS domains, and when the generation algorithm was figured out, people were able to get control of it: * https://en.wikipedia.org/wiki/Botnet#Domains https://en.wikipedia.org/wiki/Botnet#Domains * https://en.wikipedia.org/wiki/Fast_flux https://en.wikipedia.org/wiki/Fast_flux
    - dredmorbius 7y ago
      That's a separate threat model. DoH addresses surveillance, censorship, and injection by ISPs. One DNSmasq already addresses in part through various asblock and malware-blocking DNS blacklists. I'm using one such that updates hourly or better. Requests to or for specific domains my be blocked (and are). Keep in mind that by using DNSmasq at a centralised LAN server, you now have a single point of control to defend against such threats, rather than relying on multiple device- and application-specific points of control. Though software (such as browsers) offerring its own defences against such threats is in no way hindered. You can further, and more appropriately IMO, defend against such threats at the firewall level, by blocking network space (rather than domains) and ports associated with malware. At the OS level, firewalls such as Little Snitch monitor and block traffic at the application / process and user level, and may detect, alert on, and/or block such malware.
      - throw0101a 7y ago
        > * That's a separate threat model. DoH addresses surveillance, censorship, and injection by ISPs.* As does DNS-over-TLS. Though since it has an official IANA port, this can be blocked. > You can further, and more appropriately IMO, defend against such threats at the firewall level, by blocking network space (rather than domains) and ports associated with malware. And if malware leverages Cloudflare, am I supposed to block that? The ports associated with malware may be HTTPS.
        dredmorbius 7y ago
        How does DoH make any of this worse than straight UDP/53 DNS? You seem to be manufacturing a hypothetical threat that isn't actually impacted by DoH, to no clear end. Malware already exploits specific IP spaces (DUL, datacentres, AWS), and ports (20, 22, 25, 53, 80, 443, ...), as well as vectors such as adtech networks, IFRAME, and XHR. Those are blocked as best as possible, leveraging numerous signature, to varying degrees of effectiveness. Methods are not perfect. But if they on net reduce or manage risks more effectively, they're a net win. Again, DoH, either in the browser or at the LAN level, addresses a specific set of known risks. And I'm not seeing the caveats you're suggesting as either more severe or non-mitigable.

realshowbiz 7y ago

How?

Skunkleton 7y ago
Dns blacklisting of ad domains is a common technique.
- staticassertion 7y ago
  That hardly makes ads "unblockable".
  - squiggleblaz 7y ago
    At the moment you can make a tv that resolves dns using 8.8.8.8 and looks at fancy.ads to display an add in the tv guide/web browser/youtube app/whatever. But I can make my router direct any dns request back to itself and filter fancy.ads so that it never resolves to anything useful. DNS over HTTPS means that you can make a tv that resolves dns using https://8.8.8.8 https://8.8.8.8 and looks at fancy.ads. But I can't mitm it because I don't have a suitable trusted certificate to respond to that request. So either the request to fancy.ads gets dropped and the request to online.movies.example.com gets dropped so I can't use my smart tv for its intended purpose. Or both get through. Obviously things are different if the service uses standard OS level configuration so I can tell it to resolve dns using https://my.adblocked.dns https://my.adblocked.dns or /etc/hosts. But nothing obliges any particular system to do that. If my logic is faulty, please, do inform.
    - uponcoffee 7y ago
      The solution is to do as most goverments do [0]: sniff the SNI header during TLS handshakes and drop the connection if the domain matches your blocklist(s)//regex filters. [0] https://signal.org/blog/looking-back-on-the-front/ https://signal.org/blog/looking-back-on-the-front/
    - NegativeLatency 7y ago

kibwen 7y ago

It would only be a difficulty for intercepting devices like PiHoles (and I don't think it's an insurmountable difficulty either, if you control both the Pi and the computer). It wouldn't affect browser-based adblockers, which is how the majority of adblocking is already done, because browsers already have access to the unencrypted request.

15characterslon 7y ago
That would be my point too. DNS-based content blocking is very ineffective and can be outsmarted very easily. DNS filters might be very easy to set up but if they become more major they can be outsmarted very easily - what if Google starts serving ads from www.google.com, would you block that domain name too? Browser extensions can block content far more precisely. And smart TVs and such stuff could easily switch resolvers and just not use your Pihole's DNS resolver - that would work even without DoH as long as you don't intercept traffic on your router. E.g. Fire TV already adds Google DNS as an additional DNS server (you can't change that). Chromecast only uses Google DNS (AFAIK you can't change that either). I guess the only viable option here is just not to buy those products.
- tty2300 7y ago
  Or just intercept and redirect requests to googles DNS.