7 ms·

While these are all good practices, killing DoH conclusively on your home network is more difficult than you've made it seem, as ultimately all you can really d

by giobox 4y ago

While these are all good practices, killing DoH conclusively on your home network is more difficult than you've made it seem, as ultimately all you can really do is use domain blacklists at your firewall. It's no longer as straight forward as just control port 53 traffic, not like you can realistically shut down 443... Blocking DoH is largely whack-a-mole and I think is only going to get worse as this and similar techniques spread. There are so many sneaky ways to resolve a hostname an app or device can choose to use now. You can force traditional port 53 DNS protocol traffic to your own resolver with firewall rules, the same doesn't work for DoH. a DoH request to a domain your firewall blacklist doesn't have looks just like ordinary https/443 traffic and will pass unhindered.

TacticalCoder 4y ago
> While these are all good practices, killing DoH conclusively on your home network is more difficult than you've made it seem Oh I know but so far you can still ask both Firefox and Chromium to not use DoH and hence force them to use port 53 and from what I've seen they really honor that. For the moment. I don't doubt that in a not so distant future we may see companies hardcoding DoH into apps without any possibility of removing that setting! What I do is no panacea but it gets rid of a lot of things. > There are so many sneaky ways to resolve a hostname an app or device can choose to use now. But I whitelist apps that can connect to the net. Browsers, apt (for Debian/Devuan package update), the one that update the NTP/time, SSH out and that's basically it. I know it's a game of whack-a-mole, but I'm still playing it : )
LinuxBender 4y ago
Blocking DoH is largely whack-a-mole Maybe this is so but I have yet to see it. AFAIK all the DoT/DoH are on known dedicated IP addresses. I know they don't have to be. They could be on generic Akamai/CF/BunnyCDN/etc... end points but I have yet to come across one utilized in the wild. Have you found any? What are their IP addresses? I would like to add them to my DNS timing/monitoring scripts. I null route about 24 DoT/DoH IP addresses and my one smartphone seemed to figure out automagically that my router was serving up DoT on 853. I can tell if something is bypassing Unbound because there are things I know should not resolve correctly.
- JohnFen 4y ago
  > I have yet to come across one utilized in the wild How would you be able to tell?
  - LinuxBender 4y ago
    I confine everything on my network and if anything is able to resolve any one of the sanctioned countries or if the domains I override resolve to their correct address I will see it. I can only think of one opaque device I have that could even try to do that but I know it doesn't because I have to unblock .cn to get vehicle updates for it. I should add that I do not let random IoT's onto my network and that vehicle diagnostic tool from China is only on my network about once per year for a few minutes. I should also add that I have fascist firewall rules for anything I do not trust and all new SYN packets are logged. DoT and DoH use TCP.
    - JohnFen 4y ago
      You should consider filtering your HTTPS streams.
      - LinuxBender 4y ago
        Funny you should mention that. I have a few Squid-SSL-Bump proxies that I use for a few devices. For several years I even used that to visit HN and to my surprise was rarely rate limited or blocked when accessing from a VPS. With Squid I can also make decisions on content types, file sizes and more. There are only a handful of sites it doesn't work with because they for whatever reason are still using public key pinning. A few google sub-domains, eff.org, paypal but interestingly no banks. This only works with devices that I can install my own CA key onto. I have not figured out how to do that with the vehicle diagnostic tool.
        JohnFen 4y ago
        > This only works with devices that I can install my own CA key onto Yes, that's why I don't use any commercial IoT devices. I have no actual control over them. Before I shed the few I did have, I kept them segregated on their own subnet so that at least their presence didn't have to impact anything else.
denkmoon 4y ago
This is exactly why DoH is a trojan horse. You can't control it as a network administrator, all it takes is a piece of software to simply remove the controls for users to configure their own DoH and bam, end user has little to no control over how their applications perform name resolution. Little pro-tip for anyone who tries to run their own private DoH infrastructure too, Firefox doesn't like RFC1918 addresses for the DoH resolver. Set `network.trr.allow-rfc1918=true` if you run DoH on a private IP.
- noizejoy 4y ago
  > You can't control it as a network administrator That’s the design intent. Because not all network administration is benign. DoH is a tool like any other. Good or bad entirely on why and how it’s used. And your own perspective on that use case.
  - JohnFen 4y ago
    But when the network is mine, and I'm the administrator, anything that prevents me from seeing what's happening is a Bad Thing. DoH opens me up to security problems that I wouldn't otherwise have, and the extent I have to go to in order to stop it is crazy. > DoH is a tool like any other. Good or bad entirely on why and how it’s used. Except that it's a tool I have little control over, and no control over how and why it's used. That's the problem. DoH is a plague.
    - josephcsible 4y ago
      > But when the network is mine, and I'm the administrator, anything that prevents me from seeing what's happening is a Bad Thing. That's not true when the just the network itself is yours. It's only true when all of the computers on it are too. > DoH opens me up to security problems that I wouldn't otherwise have, and the extent I have to go to in order to stop it is crazy. What? No it doesn't. > Except that it's a tool I have little control over, and no control over how and why it's used. That's the problem. You're not supposed to be able to have control over what tools other people use on their own computers.
labcomputer 4y ago
But: 1. couldn’t you “just” (yea yea I know) install a cert on all your devices and force all 443 traffic though a proxy (like some corporate networks do)? 2. (Something I’ve been meaning to get around to trying for a while) default-block outgoing connections unless unless the external host was recently resolved for the corresponding internal host via your internal resolver? That seems like it would kill anything that tries to avoid your ad-blocking resolver. It seems like that might block hard-coded addresses too, but that could be a good thing..
- JohnFen 4y ago
  > force all 443 traffic though a proxy That's insufficient. There's nothing stopping a web site (or ad on a website) from forming its own DoH request that bypasses the browser and the port. It can be done entirely within the HTTPS stream.
  - tsimionescu 4y ago
    If you're monitoring the HTTPS stream, you'll see it. The point of the proxy is exactly to inspect the content of HTTPS requests (that's why you need to install your own certificate).
    - JohnFen 4y ago
      Yes, exactly. That's what I do -- I MITM all HTTPS streams for this purpose.
- Sophira 4y ago
  The biggest problem with 1) is that you lose the ability for your browser to perform checks on the certificate. If the certificate fails, the only option is to deny the connection. (Or fake it and return an error page but that can have unintended consequences.) And with 2), that would work, though you'd probably want to whitelist port 53 so that you can resolve names in the first place. Sounds like it should be effective, though.
  - 4y ago
JohnFen 4y ago
> killing DoH conclusively on your home network is more difficult than you've made it seem True. I had to install a system to MITM all my https traffic in order to block DoH requests.
- dngray 4y ago
  > killing DoH conclusively on your home network is more difficult than you've made it seem It's actually not too difficult if your users use Firefox. You can use enterprise policies https://support.mozilla.org/en-US/products/firefox-enterprise/policies-customization-enterprise/policies-overview-enterprise https://support.mozilla.org/en-US/products/firefox-enterpris... /* 0710: disable DNS-over-HTTPS (DoH) rollout [FF60+] * 0=off by default, 2=TRR (Trusted Recursive Resolver) first, 3=TRR only, 5=explicitly off * see "doh-rollout.home-region": USA 2019, Canada 2021, Russia/Ukraine 2022 [3] * [1] https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-https/ * [2] https://wiki.mozilla.org/Security/DOH-resolver-policy * [3] https://support.mozilla.org/en-US/kb/firefox-dns-over-https * [4] https://www.eff.org/deeplinks/2020/12/dns-doh-and-odoh-oh-my-year-review-2020 ***/ // user_pref("network.trr.mode", 5); It can be more of an issue if you have a lot of "smart" products or IoT products that essentially operate as black boxes on your network though. Would just recommend not doing that, if you have devices on your network that you don't control, someone else does.
  - JohnFen 4y ago
    That only affects things that use the browser's facilities to engage in DoH. A web page could decide not to do that, and manufacture their own lookups using JS, for instance.
- yubiox 4y ago
  Can you give any more detail on how you did this? Is squid the proxy? How does it know which traffic is doh? What do you do with those requests?
  - JohnFen 4y ago
    Yes, I've installed my own cert to negotiate HTTPS connections, then proxy through software to check the contents being sent. Basically the same process that some companies use for similar purposes.
mmsc 4y ago
DoH uses UDP, not TCP. Unless you're using HTTP3/QUIC, you can block port 443/UDP. And hey, maybe one day advertisements will be served directly via IP addresses, not domains:)
- josephcsible 4y ago
  > DoH uses UDP, not TCP. It uses TCP.
- dngray 4y ago
  > DoH uses UDP, not TCP. Unless you're using HTTP3/QUIC, you can block port 443/UDP. There's actually two protocols DNS over QUIC https://datatracker.ietf.org/doc/rfc9250/ https://datatracker.ietf.org/doc/rfc9250/ which has a specific port 853. This can be blocked. Then there is DNS over HTTP3 https://security.googleblog.com/2022/07/dns-over-http3-in-android.html https://security.googleblog.com/2022/07/dns-over-http3-in-an...
  - giobox 4y ago
    While these are two common standards, you can easily implement DoH almost anyway you want if you are building a service or device. Its just replying to a request for a hostname record over HTTPS fundamentally - it can be as simple as an extra REST API you run. The number of "protocols" here is effectively limitless. I cant stress enough how simple it can be - check the specs you linked, the example HTTP request/response for the DNS over HTTP3 example is really basic - you could build your own in less than an hour if you really wanted and understand how traditional DNS works. There is no such thing as right or wrong way to do DoH so long as the DNS messages are passing over HTTPS - the standards are largely to help make it easier to deploy and avoid common pitfalls of course (simpler to integrate to browsers and other software "for free" if the message response body format is standardised), but devices, apps and even javascript in the browser are free to solve this anyway they want, with whatever kind of message payload they can dream up. DoH is just an HTTP request over SSL in most implementations, nothing more, with the record usually in the payload body in a JSON message or similar.
- giobox 4y ago

by giobox 4y ago

TacticalCoder 4y ago

> While these are all good practices, killing DoH conclusively on your home network is more difficult than you've made it seem Oh I know but so far you can still ask both Firefox and Chromium to not use DoH and hence force them to use port 53 and from what I've seen they really honor that. For the moment. I don't doubt that in a not so distant future we may see companies hardcoding DoH into apps without any possibility of removing that setting! What I do is no panacea but it gets rid of a lot of things. > There are so many sneaky ways to resolve a hostname an app or device can choose to use now. But I whitelist apps that can connect to the net. Browsers, apt (for Debian/Devuan package update), the one that update the NTP/time, SSH out and that's basically it. I know it's a game of whack-a-mole, but I'm still playing it : )

LinuxBender 4y ago

Blocking DoH is largely whack-a-mole Maybe this is so but I have yet to see it. AFAIK all the DoT/DoH are on known dedicated IP addresses. I know they don't have to be. They could be on generic Akamai/CF/BunnyCDN/etc... end points but I have yet to come across one utilized in the wild. Have you found any? What are their IP addresses? I would like to add them to my DNS timing/monitoring scripts. I null route about 24 DoT/DoH IP addresses and my one smartphone seemed to figure out automagically that my router was serving up DoT on 853. I can tell if something is bypassing Unbound because there are things I know should not resolve correctly.

JohnFen 4y ago
> I have yet to come across one utilized in the wild How would you be able to tell?
- LinuxBender 4y ago
  I confine everything on my network and if anything is able to resolve any one of the sanctioned countries or if the domains I override resolve to their correct address I will see it. I can only think of one opaque device I have that could even try to do that but I know it doesn't because I have to unblock .cn to get vehicle updates for it. I should add that I do not let random IoT's onto my network and that vehicle diagnostic tool from China is only on my network about once per year for a few minutes. I should also add that I have fascist firewall rules for anything I do not trust and all new SYN packets are logged. DoT and DoH use TCP.
  - JohnFen 4y ago
    You should consider filtering your HTTPS streams.
    - LinuxBender 4y ago
      Funny you should mention that. I have a few Squid-SSL-Bump proxies that I use for a few devices. For several years I even used that to visit HN and to my surprise was rarely rate limited or blocked when accessing from a VPS. With Squid I can also make decisions on content types, file sizes and more. There are only a handful of sites it doesn't work with because they for whatever reason are still using public key pinning. A few google sub-domains, eff.org, paypal but interestingly no banks. This only works with devices that I can install my own CA key onto. I have not figured out how to do that with the vehicle diagnostic tool.
      - JohnFen 4y ago
        > This only works with devices that I can install my own CA key onto Yes, that's why I don't use any commercial IoT devices. I have no actual control over them. Before I shed the few I did have, I kept them segregated on their own subnet so that at least their presence didn't have to impact anything else.

denkmoon 4y ago

This is exactly why DoH is a trojan horse. You can't control it as a network administrator, all it takes is a piece of software to simply remove the controls for users to configure their own DoH and bam, end user has little to no control over how their applications perform name resolution. Little pro-tip for anyone who tries to run their own private DoH infrastructure too, Firefox doesn't like RFC1918 addresses for the DoH resolver. Set `network.trr.allow-rfc1918=true` if you run DoH on a private IP.

noizejoy 4y ago
> You can't control it as a network administrator That’s the design intent. Because not all network administration is benign. DoH is a tool like any other. Good or bad entirely on why and how it’s used. And your own perspective on that use case.
- JohnFen 4y ago
  But when the network is mine, and I'm the administrator, anything that prevents me from seeing what's happening is a Bad Thing. DoH opens me up to security problems that I wouldn't otherwise have, and the extent I have to go to in order to stop it is crazy. > DoH is a tool like any other. Good or bad entirely on why and how it’s used. Except that it's a tool I have little control over, and no control over how and why it's used. That's the problem. DoH is a plague.
  - josephcsible 4y ago
    > But when the network is mine, and I'm the administrator, anything that prevents me from seeing what's happening is a Bad Thing. That's not true when the just the network itself is yours. It's only true when all of the computers on it are too. > DoH opens me up to security problems that I wouldn't otherwise have, and the extent I have to go to in order to stop it is crazy. What? No it doesn't. > Except that it's a tool I have little control over, and no control over how and why it's used. That's the problem. You're not supposed to be able to have control over what tools other people use on their own computers.

labcomputer 4y ago

But: 1. couldn’t you “just” (yea yea I know) install a cert on all your devices and force all 443 traffic though a proxy (like some corporate networks do)? 2. (Something I’ve been meaning to get around to trying for a while) default-block outgoing connections unless unless the external host was recently resolved for the corresponding internal host via your internal resolver? That seems like it would kill anything that tries to avoid your ad-blocking resolver. It seems like that might block hard-coded addresses too, but that could be a good thing..

JohnFen 4y ago
> force all 443 traffic though a proxy That's insufficient. There's nothing stopping a web site (or ad on a website) from forming its own DoH request that bypasses the browser and the port. It can be done entirely within the HTTPS stream.
- tsimionescu 4y ago
  If you're monitoring the HTTPS stream, you'll see it. The point of the proxy is exactly to inspect the content of HTTPS requests (that's why you need to install your own certificate).
  - JohnFen 4y ago
    Yes, exactly. That's what I do -- I MITM all HTTPS streams for this purpose.
Sophira 4y ago
The biggest problem with 1) is that you lose the ability for your browser to perform checks on the certificate. If the certificate fails, the only option is to deny the connection. (Or fake it and return an error page but that can have unintended consequences.) And with 2), that would work, though you'd probably want to whitelist port 53 so that you can resolve names in the first place. Sounds like it should be effective, though.
- 4y ago

JohnFen 4y ago

> killing DoH conclusively on your home network is more difficult than you've made it seem True. I had to install a system to MITM all my https traffic in order to block DoH requests.

dngray 4y ago
> killing DoH conclusively on your home network is more difficult than you've made it seem It's actually not too difficult if your users use Firefox. You can use enterprise policies https://support.mozilla.org/en-US/products/firefox-enterprise/policies-customization-enterprise/policies-overview-enterprise https://support.mozilla.org/en-US/products/firefox-enterpris... /* 0710: disable DNS-over-HTTPS (DoH) rollout [FF60+] * 0=off by default, 2=TRR (Trusted Recursive Resolver) first, 3=TRR only, 5=explicitly off * see "doh-rollout.home-region": USA 2019, Canada 2021, Russia/Ukraine 2022 [3] * [1] https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-https/ * [2] https://wiki.mozilla.org/Security/DOH-resolver-policy * [3] https://support.mozilla.org/en-US/kb/firefox-dns-over-https * [4] https://www.eff.org/deeplinks/2020/12/dns-doh-and-odoh-oh-my-year-review-2020 ***/ // user_pref("network.trr.mode", 5); It can be more of an issue if you have a lot of "smart" products or IoT products that essentially operate as black boxes on your network though. Would just recommend not doing that, if you have devices on your network that you don't control, someone else does.
- JohnFen 4y ago
  That only affects things that use the browser's facilities to engage in DoH. A web page could decide not to do that, and manufacture their own lookups using JS, for instance.
yubiox 4y ago
Can you give any more detail on how you did this? Is squid the proxy? How does it know which traffic is doh? What do you do with those requests?
- JohnFen 4y ago
  Yes, I've installed my own cert to negotiate HTTPS connections, then proxy through software to check the contents being sent. Basically the same process that some companies use for similar purposes.

mmsc 4y ago

DoH uses UDP, not TCP. Unless you're using HTTP3/QUIC, you can block port 443/UDP. And hey, maybe one day advertisements will be served directly via IP addresses, not domains:)

josephcsible 4y ago
> DoH uses UDP, not TCP. It uses TCP.
dngray 4y ago
> DoH uses UDP, not TCP. Unless you're using HTTP3/QUIC, you can block port 443/UDP. There's actually two protocols DNS over QUIC https://datatracker.ietf.org/doc/rfc9250/ https://datatracker.ietf.org/doc/rfc9250/ which has a specific port 853. This can be blocked. Then there is DNS over HTTP3 https://security.googleblog.com/2022/07/dns-over-http3-in-android.html https://security.googleblog.com/2022/07/dns-over-http3-in-an...
- giobox 4y ago
  While these are two common standards, you can easily implement DoH almost anyway you want if you are building a service or device. Its just replying to a request for a hostname record over HTTPS fundamentally - it can be as simple as an extra REST API you run. The number of "protocols" here is effectively limitless. I cant stress enough how simple it can be - check the specs you linked, the example HTTP request/response for the DNS over HTTP3 example is really basic - you could build your own in less than an hour if you really wanted and understand how traditional DNS works. There is no such thing as right or wrong way to do DoH so long as the DNS messages are passing over HTTPS - the standards are largely to help make it easier to deploy and avoid common pitfalls of course (simpler to integrate to browsers and other software "for free" if the message response body format is standardised), but devices, apps and even javascript in the browser are free to solve this anyway they want, with whatever kind of message payload they can dream up. DoH is just an HTTP request over SSL in most implementations, nothing more, with the record usually in the payload body in a JSON message or similar.
giobox 4y ago