This will mean that using firewall filters that use tls-host= (or L7 filters that try to do the same thing) to “block certain websites” will become ineffective for users that use the Firefox browser.
Routers will no longer be able to determine what websites users are visiting, at least not without doing man-in-the-middle decryption of TLS (https). Which is only possible for managed devices in companies, not for random visitors or clients of your ISP.
Filtering by IP address is usually not practical because they change all the time and can be shared between different sites.
So prepare for your Youtube filters to become ineffective!
Or just block based on IP or IP address ranges. Just like always because for years we knew this was coming.
You can also block the IP addresses of the DOH servers like I did today when Firefox always want to inform dooh.cloudflare.com that I just started the browser. And yes, I disable DOH in Firefox but they wipe their ar.. with my choice, so I had use the firewall to block that exchange of digital information.
Well, the issue is that “secure” can have different definitions depending on the viewpoint. The people at Firefox (and some vocal organizations) consider it “secure” when only the end-user can see what data is on their display. See also the campaign to promote https and deprecate http. The (pre-existing) TLS protocol still exposed the hostname of the connected system, as that wasn’t a design consideration at all when it was designed. But this new “security against monitoring” still left the desire to hide that info as well. Which is now done.
Of couse such “security against monitoring” (as a protection of privacy) can be conflicting with security of other aspects, and this now shows. Owners of networks may want to prohibit certain usage, not to peek into the user’s behavior but to protect their network against abuse (relative to the intended purpose) or over-use (relative to its limited capacity). That capability has now been removed, and therefore a network may collapse under overload, reducing availability. It may even result in some open WiFi networks closing down because they can no longer afford to provide the service in a way that keeps it usable, or its usage within their terms of service.
The problem is that you cannot block services that run on large CDN or other server farms like Google’s in that way.
When you even can find all addresses used by Youtube, you may find that the same addresses are used by Gmail, for example.
That’s exactly what I mean. DoH and better encryption for the users can’t be done, while keeping network admin desire to block webpages. And at the same time, the network admin is complaining about telemetry of the browser. He wants to be secure himself, but still wants to spy on his own users
Sorry Normis, I don’t want to spy on myself and I don’t want to be spied on by others. So DOH is in a internal network a curse and I wrote many times before that DOH is made for war time or for regimes that don’t give a sh.. about the rights of their citizen. I seem to live also under that kind of regime in the Netherlands.
I have other means to circumvent that Big TECH/GOV brother is watching me all the time and everywhere.
The problem is that programs/APP can hide their behavior and those are mostly sponsored or even designed by Big TECH/GOV to gather information about you.
I came here this morning to start initiative to generate a IP-address/domain list of known DOH servers that are know by us so a owner of a Mikrotik device can use to block those servers from being reached from the inside of the network.
I block myself only from internal network UDP/TCP 443 and ICMP to those IP addresses. If a owner want to use a DOH client as on the router itself than that is allowed just as using the DOH block list. I think UDP is not being used in DOH, but just be certain.
I use a list that can be imported directly into an addresslist in the router and the list can be dynamic by providing only the domains or a IP-address that is static till the next update. It could be a mixed list and a domain will stay inactive till the IP-address of that domain changes (not tested). The import is done by import and creating a temporary list and then swap that one out with active one so the down time is minimal.
Additions can be suggest here and I will add those to the list which is then published.
…those are sites that you only should touch with a very long set of pliers! The best is to find ASAP alternatives for them or just go back to before they existed.
I just check if the canary domain is inactive but it it is still there and giving a NXDOMAIN as resolve. So Firefox is clearly not obeying it anymore because they have their head somewhere else all the time.
Its no ones business (ISP, google) etc, to see what I am doing.
On the other hand…
I may not want my network to be used for destructive social programs such as instagram or facebook etc… even if just temporarily aka 6 months.
I have come to the conclusion is that the best way ahead is to ensure vlans separate users/devices networks from each other as required so that if an individual wants to endanger themselves, so be it, but hopefully its limited to that subnet/vlan. A little more difficult to do on WIFI, as there are not infinite wlans…
The purpose of the use-application-dns.net domain was to tell Firefox in a network that the network admin does not want the users to use DoH.
The domain is registered on internet and one is supposed to override that in a local static entry with an NXDOMAIN response.
I even asked MikroTik to allow local static entries with NXDOMAIN result, which they implemented. And it worked.
But according to msatter (I did not test it myself yet), now Firefox does not query the domain anymore… sad.
In fact I had planned to find if there was another such domain to tell Firefox not to do the ECH but that seems unlikely then.