DNS-over-HTTPS Policy Requirements for Resolvers(blog.mozilla.org) |
DNS-over-HTTPS Policy Requirements for Resolvers(blog.mozilla.org) |
So can I manually set one myself to my local pi-hole instance? I have already been setting the TRR about:config values (ala [0]), will that remain?
I am wary of Mozilla becoming the arbiter of acceptable DNS providers for me, so I should be able to override it if I want.
0 - https://blog.stackpath.com/serverless-dns-over-https-at-the-...
There's no way we should take that information and centralise it into the hands of a few big providers. No matter how many pinky promises they make to not look at it.
Both of the above need to be urgently reined in to retain some sense of accountability and democracy. And these efforts including awareness are predominantly coming from outside the technical community.
When the problem is concentrated global monopolies and power how can centralizing more control be the solution? And yet these seem to be the only solutions from the community.
I work at a k12 school and I am involved on many k12 IT communities.
Some schools already removed Firefox from the students computers because it was being used as a "VPN" by some elementary students to access porn - at school. Guess what this VPN was? Just DNS over HTTPS.
There is a fine line between protecting yourself from your ISP and local network operators that NEED to apply some security policies to their traffic. Even Google offers "Safe Search" for schools and libraries that removes porn content.
Unfortunately, on our school network, we also allow BYOD (students with their own laptops and ipads), so we will have to have some strict rules to block DoH, the same way we block proxies and vpns.
The only other option is going to full HTTPS MITM, forcing a root SSL cert to all computers that use our network, which is the last thing that anyone wants to do.
Summary: This may lead to more HTTPS MITM or schools forbidding BYOD AND removing Firefox from their computers.
The very least the new tech provides is that any silent helicopter parenting is becoming more visible and I'm grateful for that. Kids deserve internet privacy just as much as real-life privacy.
If you think that this is how it will go, you're very naive. If schools and parents can't block porn anymore, prepare for more legislation that blocks porn by default at the ISP unless you pay some kind of fee - like what the UK has proposed. Also look for a return of "content standards" for sites that want to be kept off the "porn list", like the old broadcast TV content standards.
And yeah the actual solution is "don't fucking give a six year old an Internet-connected device of any sort, obviously, you idiots" but they do, so monitoring and blocking are absolutely necessary.
What these schools need is to set up sensible group policies. Managing BYOD on a school with kids (as opposed to grown-up people whose jobs are on the line) is simply impossible.
This could become a major hassle if the number of devices and owners become large. There's not even a work around for this because I do not directly manage family members' devices (nor would they want me to).
I really like Firefox for they are the only real option these days. I use it and I encourage all those around me to use it. This change will require me to do a lot more manual work and likely lead to confusion over whether a service is down or not.
And whatever Gaming app the kids download? Suddenly it will become impossible to manage and maintain.
Not even talking about the troubleshooting nightmare.
DNS should be a system-level setting, not an App-level setting.
How can you block DoH without doing MITM on all outgoing HTTPS? For that matter, how can you block HTTPS based VPNs like OpenVPN?
ETA: I understand you can block IP addresses of DNS resolvers that support DoH. I assumed that to make this work, Mozilla / Google / etc. would serve DoH from the same IPs as some big services, so you wouldn't be able to block DoH without blocking something like Google's homepage.
OpenVPN isn't HTTPS based. It has TLS support, but AFAIK it's implemented as TLS-over-OpenVPN rather than OpenVPN-over-TLS, so it's still very distiquishable from a HTTPS connection. There are workarounds like using TCP mode over stunnel, though.
Won't prevent someone from setting up its own SSH-based proxy on port 443, but covers things that are accessible and easy to use by young students (talking about elementary school on our case).
Again, we are talking about a school network with young kids (under 12/13).
That's kind of the entire point of DoH. DNS-over-TLS (DoT) provides TLS encryption for DNS traffic, but runs over port 853 so network operators can control where queries go.
I guess a solution is MDM, but that's still getting students to install something on their device.
Firefox now has enterprise support where the administrator can force all desktops to use certain Firefox settings including enabling/disabling/configuring DoH.
See https://www.mozilla.org/en-US/firefox/enterprise/
And here's a link to details for configuration DNS over HTTPs. https://github.com/mozilla/policy-templates/blob/master/READ...
(I work at Mozilla)
DNS is a band-aid solution with side effects.
Worked in your arena for 5 years. Kids are creative and crafty. We had kids getting around the MDM/DNS blocks by changing the DNS/Proxy settings in their iPads. This is not easily overcome with existing MDM solutions AND letting the iPad be usable. BYoD is a whole different animal since you cannot legally "touch" their devices, you have to implement the federally-mandated blocks at the infrastructure level. Kids can use VPNs all day and there is nothing that can be done in reality.
At a previous job, believe it or not, I worked with a client with almost a zero budget who was having massive issues with malware/ads in their public space that offered free computer use. Being the budget was minimal (less and $100 to fix), I deployed two Pi-holes and taught the "admin" how to manage it. Cheap, effective, works. I set the whole thing up to fail back to the network's DNS should the Pi-holes fail. Still running almost two years later.
The Pi-hole can block about any content you would like it to block with almost zero-configuration. Easy to block a single domain or with a new rule set subscription.
Our student's data was still private (no emails or passwords being decrypted) and we did the filtering only based on the domain name. It also didn't require an expensive appliance that would be need if did the filtering based on SNI.
The fact that it is enabling students (or anyone) to bypass restrictions is a good thing.
Why don't you try looking at this from another point of view. Firefox is a powerful important tool, and I want it to continue to be so, even if it is not ideal for everyone.
They deserve their internet privacy just as much as grown ups do even more so actually given their higher trust in others, if schools are scared of internet's dangers then schools should educate, not wrap kids into digital bubble wrap that will disappear when they leave school leaving them tech-illiterate and vulnerable.
If the school cannot be bothered to block content properly (ie, only via DNS block) then that is their own fault. The tools exist to block on an IP level.
For all computers the school owns, they SHOULD definitely do HTTPS MitM.
SNI filtering is a reasonable middle ground - it has its flaws but nowhere near invasive as full MITM filtering yet achieves most of the filtering objectives of the organisation. Ie it is “good enough”. Sadly ESNI may be the end of usefulness of this approach.
I expect that we'll see this sort of thing more and more.
As a consequence I would not use your network. This may also be considered success from your point-of-view.
DNS filtering was always easily circumvented; a time sucking cat and mouse game at best.
That goes into the argument that DNS (domain name lookup) should be a system and network-level setting, not an App-based setting.
It's going to be particularly god-awful for devices that roam between networks where the "internal" DNS is visible and networks where it isn't. Ugh...
network.trr.mode
That’s part of the plan. From now everything is cloud only, and everyone doing anything differently gets thrown under the bus, with less and less control left for the user.
We’re progressing backwards into the future.
https://youtu.be/OxFFTxJv1L4?t=2799
After hearing Dr. Vixie discuss DNS-over-HTTPS from a network operator perspective I'm a lot more wary of the protocol.
What I perceive from the debate is generally that people who dislike DoH tend to perceive it as a network plane protocol, one that is designed for network operations and nothing more (layer 3/4 if you will).
Whereas people who tend to want privacy and the other features of DoH, perceive it as an application level concern (layer 7). In this context connectivity and discoverability of services is the aim, and knowing that the information for establishing connections to those services is correct is important to the foundations and guarantees of applications being built to utilize DNS.
In the application and services context, you may not even want a single set of recursive resolves or authorities for the system. And the reasons are to help ensure the data is focused on what you need in different contexts.
I believe that the network level concerns over DoH are a little disingenuous, and this is because there are many ways to circumvent DNS, DoH isn’t necessary, you don’t even need DNS to establish layer3/4 connections. Fighting over DoH for security that can’t truly be enforced in DNS, seems misguided.
I sometimes use a local resolver bound to localhost that blocks ads by pointing to a custom root.
If someone aiming to be on the TRR list sets up a remote resolver that blocks ads (or replaces them with blank images) perhaps using the same technique, it could allow Firefox users to get ad blocking by default, by using DOH.
I wonder if that would violate Mozilla's requirements?
Are ads considered "content"?
There is of course precedent for blocking undesirable content via DNS as a "service".
Third party DNS service, for example the famous one that starts with "O", has been used to block certain content, e,g, at schools.
This was offered as a fee-based service.
If I remember correctly they also offered "free" service which was subject to redirection of NXDOMAIN to paid placement "search" results/ads.
We have implemented DNS over HTTPS [RFC8484] and would like to
deploy it by default for our users. We intend to select a set of
Trusted Recursive Resolvers (TRRs) that we will use for DoH
resolution.
Presumably you can still configure your machine to use whichever resolver(s) you want.
The real question is if you're allowed to use your own resolver that conforms to your requirements if they differ from Mozilla's, even if a bit buried from the default list,
In addition, collection and analysis of below-the-recursive DNS traffic is one of the primary ways in which security researchers discover the infrastructure of botnet networks.
Overall DoH is probably a net positive, but I don't see downsides like this being discussed.
Yeah, Erdoğan won't be able to block oppositions' web sites. That is a very big threat! /s
DOH can be implemented directly inside of the web browser application, since those browsers are obviously already doing everything over HTTPS. So the browser developers just have to build in a DNS client. From their perspective, I would see that being much simpler. And deployment is as easy as the next browser application update.
Are you sure? My experience so far has shown that only dnscrypt is widely supported.
Nevertheless, surely they must had some kind of issue with the existing solutions when they started working on it.
As for DNS over QUIC, I was under the impression that said solution did not make use of HTTP.
If I were to set up my own DoH server, would its queries to upstream (root??) servers (and subsequent recursed servers) be encrypted? (Simpler: does running a DNS server "on-premise", or even in the cloud, actually protect you from anything?)
Recursive lookups from the resolver to authoritative DNS servers from the root down are not encrypted.
Really what you are doing is switching between telling your ISP all the domains you look up to telling Google/Cloudflare. Except your ISP can still see SNIs so you’re really just telling Google/Cloudflare in addition to your ISP.
I don't suppose there are any proposals to replace how SNIs are transmitted? (sans-vpn/tor, that is)
Does QUIC/HTTP[23] do anything different?
network.security.esni.enabled
https://blog.cloudflare.com/encrypt-that-sni-firefox-edition...
I wonder how this plays out with local DNS (e.g. my ISP has some custom domains for me to use, and internal company network addresses)
Firefox will ignore your DNS settings and use his own (DoH)
The article talks about Firefox behavior when DoH is enabled. It's not enabled by default. The article doesn't say it's getting enabled by default, or under what conditions it might get enabled by default.
"Over the past few months, we’ve been experimenting with DNS-over-HTTPS (DoH), a protocol which uses encryption to protect DNS requests and responses, with the goal of deploying DoH by default for our users."
https://mailarchive.ietf.org/arch/msg/doh/po6GCAJ52BAKuyL-dZ...
“4. The user will be informed that we have enabled use of a TRR and have the opportunity to turn it off at that time, but will not be required to opt-in to get DoH with a TRR.”
Thanks for posting this. I knew Paul is against DoH, but never understood his specific arguments. He has great comment about DoT (dns over TLS) couple of minutes before the linked youtube (I agree with him on that).
Personally I'm not an "owner" of the networks I'm connecting to. My home router is managed by my ISP, I don't run pi-hole. Network at work is managed by yet-someone-else. I often use my mobile carrier (LTE tethering), and often use WiFi at coffee shops.
For all of these cases I would prefer to not expose my DNS traffic. Heck, I'm 100% sure that my dns traffic today is being re-sold! I have couple of unique domain names that I have open in my browser which have unique and non-guessable DNS names, which are crawled by some bots today. Even though I never shared them in any way with anyone! The only way they could be exposed for crawling is by my DNS provider leaking the DNS traffic to some shady third-party.
Many DNS people are opposed DoH, but I think this train has passed. As a user of the internet I really do want encrypt everything these days. https://tools.ietf.org/html/rfc8404
If my corporate boss, or my ISP can mine less data about the malware I'm running - so be it. For me this is an acceptable cost of measurably improved privacy.
Not true.
They may be connecting directly by IP (it's typically not possible to determine if they did just from access logs). The web (or other application) server may also leak the name when connected to.
If you use TLS, which is likely, your domain names would leak through the certificate transparency logs.
...and there are surely more leak vectors than the above, so it's far from certain that the crawlers you see found their target by sniffing your DNS requests.
There are a number of other, perhaps more likely, reasons your hostnames have leaked.
Have you got any certificates for any of those names? Then they are in the public CT database which numerous people constantly scan for interesting data.
Are any of your DNS zones enumerable for some reason? Same thing. Any reverse DNS set up? What protocols and public services do you run? Do any expose hostnames in the protocol handshake? Then you are in the public Internet scan datasets.
As soon as you run any kind of SSL on any of your protocols your hostname is in the SNI header.
Host names are visible in a number of ways. It is best to consider them public data. I have seen a number of ISPs from the inside, and none of them has had any interesting in wiretapping their customer's DNS data. I'm not saying it doesn't happen, but it can't be very common. They have much more interesting data available to them should they want to go down that road.
But I am the owner of my own network, and DoH reduces my ability to protect it. That is the main (but not only) reason why I strongly object to DoH.
> I think this train has passed.
I suspect the battle has just begun. For example, my response to DoH has been to implement a MITM packet inspection system on my network to regain control over this. This means that DoH will not work from my network. I expect that we're going to see this sort of thing more and more.
Some schools already started to block Firefox from being installed because it was being used as a "VPN" by some elementary students to access porn - at school. Guess what this VPN was? Just DNS over HTTPS.
There is a fine line between your ISP and local network operators that NEED to apply some security policies to their traffic. Even Google offers "Safe Search" for schools and libraries that removes porn content.
Unfortunately, on our school network, we also allow BYOD, so we will have to have some strict rules to block DoH, the same way we block proxies and vpns.
Don't push things into applications and make things more difficult for everyone else when you can secure your own computer.
That’s not a very good governance strategy.
>[Mozilla] believe that they need to build technology that will accommodate a hostile network operator who is going to replace your DNS with things pointing to their advertising servers or is going to monitor what you do and send it off to some human rights violation team somewhere and so rather than tell you to use VPNs or tell you to use tor they decided to build DNS into the web
Requiring the average Joe to use a VPN service just so they can have some reasonable attempt at privacy isn't really an option, as we have seen. Privacy shouldn't be a luxury reserved only for those who can afford it. What I would really like to see is our lawmakers step up and make modern privacy laws with respect to technology and the data that results of it, but that clearly isn't happening. Unfortunately, DNS-over-HTTPS will very likely be used against the consumer in the long-run. Instead of using a pi-hole with port 53 blocked, I can see many devices will start using DNS-over-HTTPS to bypass those restrictions. Chromecast, rokus, and other devices already have hard-coded DNS addresses built-in, it won't be a very large step for them to switch to DNS-over-HTTPS to bypass my own network policies.
So the options are: * Make DoH illegal somehow * Take advantage of it as best we can
Think a corporate network. If I as a sysadmin set our DHCP options to give out our own resolvers, I expect that every machine on the domain to use ours.
DoH breaks that completely; and hence the network operator should have the final say.
As a sysadmin myself, if browsers are overriding the basic model of top down, and it hurts me, because when something is wrong, I cant just look on my machine, I have to check which browser they use... that is the antithesis of the problem, because when DoH doesn't work but normal DNS does, then I'm flat out of options.
This is why I choose not to use Firefox or any of the DoH mainline providers (Cloudflare,) and I go out of my way to make sure users cant do it.
Dns over https creates more problems than it solves for 99% of end users.
And why is that an unreasonable position for a network operator to hold?
I’ve actually actively blocked DoH for the major providers on my router, by writing some custom iptables rules.
Hopefully there will be a simple to use OpenWrt-package which you can install to do this automatically in the future.
DoH gains me nothing since I already tunnel the traffic to my resolver. What I really want is something like dnscurve.
1. content policies: blocking porn, censorship, etc (already easily circumvented by changing DNS or using a VPN)
2. preventing malware command and control: blocking domains that malware phones home to (already easily circumvented by including their own resolver, etc)
3. preventing malware infection: blocking domains serving malware (you might lump "ads" in this category too, e.x. Pi-hole)
IMHO the 3rd is the only use-case worth trying to solve with DNS blocking, because the user isn't actively trying to circumvent it.
Applications using their own resolvers do make that difficult to do. It seems like it would be best if operating systems implemented DoH at the system level, including DHCP support, so devices could use the network's DoH resolver which might do malware blocking.
Applications like Firefox could fall back to their own DoH resolver if they had a way to detect the system was not using DoH. This would also encourage network operators to support DoH.
They already do that. It’s called DNS.
I disagree. The problem with DoH is that it masquerades DNS lookups as web traffic. Other means of doing DNS lookups, encrypted or not, can be easily determined to be DNS lookups and handled according to the network policies.
By disguising the lookups as web traffic, it means that I can no longer leave web traffic alone. I have to MITM HTTPS now. If they were happening on their own ports, I would have less invasive methods available, such as running my own resolver.
The reason I made that statement has to do with the means by which DNS can easily be circumvented and direct encrypted connections used instead. This means using DNS introspection as a means for security doesn't buy you much, DoH just makes that more apparent.
It isn't. Sorry my sarcasm didn't come through clear enough, but what you're saying and disagreeing with is my point.
See you're missing something. If you as the local network operator can't block porn than neither can any intermediate ISP. It's not like they have any more power than you do.
And Cloudflare already does expose DoH on all addresses, as long as SNI/Host header is one of the vhost hostnames. You can currently make DoH requests to cloudflare-dns.com , the "mozilla" subdomain, one.one.one.one, 1.1.1.1, and 1.0.0.1 (there may be others that i'm not aware of ).
As school network admin in another life I came to the conclusion that there is no limit to the ingenuity of pupils even at that age. And I'm just thinking that even big hitters like Netflix have problems properly filtering out VPN services and the likes. Anything-as-a-service makes it all the more accessible to anybody even for free.
Try to disable DOH if you can for now while you prepare something more permanent and resilient. Kids viewing pornographic material in school is a lawsuit waiting to happen I think.
Hopefully for BYOD parents will take a bit of the load off. At least tech savvy ones tend to make sure the device is properly "insulated". Plenty of lockdown options out there for this.
However, I'm not completely heartless. I also run an open WiFi AP that, although limited, is available for guests who aren't comfortable with my security measures. You can't reach the rest of my network through it, but it's there and will get you internet access.
Of course DoH will break this and leak. Enterprises everywhere will hate this and ban Firefox.
I believe it's possible to do both direct DNS over QUIC and ((DNS over HTTPS) over QUIC).
https://android-developers.googleblog.com/2018/04/dns-over-t...
You're free to do whatever you like with devices that you own and you're also free to have an acceptable use policy on your network but breaking security and privacy to accomplish it is the exact wrong way to go about it.
In my ideal world school BYOD devices would either not be allowed at or be given a private single-device VLAN with a direct unfiltered connection upstream, and made clear in policy that the school doesn't own, support, or control any aspect of them. No different whatsoever than students using their cellular connection.
If you are MitMing all encrypted traffic anyway, why not block whatever you want to block when someone actually tries to connect to it, rather than trying to prevent them from learning where it is?
I want to maintain the ability to block the resolution of certain domain names.
The threat model is malicious software or websites that want to phone home. This includes reaching out to command-and-control servers, ad tracking servers, data exfiltration points, etc.
> If you are MitMing all encrypted traffic anyway, why not block whatever you want to block when someone actually tries to connect to it
Because most of the malicious actors don't use raw IP addresses as they can change frequently and without notice. They resolve a domain name instead. Blocking the domain name lookup is therefor more effective and less likely to result in blocking the wrong things than working with raw IP addresses.
This is not a replacement for other security measures (including IP-based blocks), but is is, in my opinion, a critical measure in and of itself.
You're thinking of configuring a custom DNS server, which is not related to the hosts file. The hosts file replaces DNS so there would be no network traffic to block.
Theoretically a kid who really wants his porn could manually add the name-to-IP entries for his favorite sites to his local hosts file, completely bypassing any DNS based filtering you might have on the network.
Maybe the occasional brilliant kids will find a way, good for them. But there's a limit to how much "ghetto administration" you can do without expending any resources on it and still have your measures hold after a few weeks of curious students probing at them.
And for HTTP/1.1 it should use WebSocket for a persistent connection, but probably it already targeted HTTP/2.
The easiest work-around for students who want to show their mates some "cool porn" is to just save it at home. Or connect to the free wifi of <random shop> in reach.
All of these use domain names to set up the communications, for obvious reasons, so being able to thwart those lookups is of great value.
You're right, that all by itself is insufficient, but it's still very important.
In the case of BYOD, if you're not okay with your kid having an Internet-connected device and that they're going to use it responsibly then don't give him/her one or only allow it under parental supervision. If we're carefully watching and teaching kids kids when they're handling knives or matches, why not do so with internet connected devices?
Because some parents would.
Parent would still complain.
The solution isn't to play helicopter-parent because other parents might helicopter even more.
Some parents complain about sex ed and vaccination, satisfying the lowest common denominator doesn't really work.
If some kid showed actually NSF-School images, such as nudity, to other kids and it was a first time offense a warning should suffice. If it's a repeated offense then maybe the kid needs psychological help.
Just as a hypothetical scenario, there's the possibility that a kid shows others a picture of for example Michelangelo's David (or similar art piece), do you think that kid should be punished for showing nudity to other kids?
Instead I ended up with these lines in /etc/config/firewall:
config rule
option target 'ACCEPT'
option name 'Allow router to perform DNS'
option family 'ipv4'
option src_ip '192.168.1.1'
option dest_port '53'
option src '*'
option dest '*'
config rule
option src 'lan'
option name 'Disallow Google DNS from LAN'
option family 'ipv4'
option dest_ip '8.8.8.8'
option target 'REJECT'
option dest 'wan'
config rule
option src 'lan'
option name 'Disallow Google DNS from LAN (2)'
option dest 'wan'
option family 'ipv4'
option dest_ip '8.8.4.4'
option target 'REJECT'
config rule
option src 'lan'
option name 'Disallow Cloudflare DOH from LAN'
option dest_ip '1.1.1.1'
option dest_port '443'
option target 'REJECT'
option proto 'tcp'
option family 'ipv4'
option dest 'wan'
config rule
option src 'lan'
option name 'Disallow Cloudflare DOH from LAN (2)'
option proto 'tcp'
option dest 'wan'
option dest_ip '1.0.0.1'
option dest_port '443'
option family 'ipv4'
option target 'REJECT'
config rule
option src 'lan'
option name 'Disallow Cloudflare DOH from LAN (3)'
option dest_ip '104.16.249.249'
option family 'ipv4'
option dest 'wan'
option target 'REJECT'
Router itself acts as a DNS-server via dnsmasq, and is allowed to do anything I decide I want.
On my network I have a pi-hole instance which then forwards queries to the router, so it also intercepts/looks up local LAN names correctly.
All clients on the network are provided the pi-hole as the canonical DNS-server to use via DHCP options.
Works for me.
Oh- adnetwork.example.com. Probably serving up ads.
Oh Agrrvxdrgkndzzzvbbhydsxxjjj.net.org.com. Probably botnet related.
Vs
I need to look at every protocol flow and sort by IP?
Who in their right mind blindly trusts all computers like this? If you ever want to troubleshoot your network, your job becomes way more tedious if dns requests are encrypted.
Because the we're dealing with computers as they actually exist and are configured. And within epsilon every personal computer on the planet is configured to trust DHCP and set their DNS servers to whatever is offered. So we're in a situation where these particular applications also don't really trust the OS to a certain extent.
As for the DHCP part, if you're on a public network you should only trust it as far as you need it to bootstrap your tunnel over which you can then finally contact a trusted resolver.
OS resolver -> a single thing you need to secure every app uses its own resolver -> complete mess which makes it harder to ensure privacy of your traffic
I absolutely agree that DNS should be a system-level concern rather than app-level. But today, right now, for computers as they are and will continue to be for the foreseeable future this is a huge improvement. Browsers being the app that handles basically all of our sensitive information I think have earned the exception.
- Cry about it and hope they change the policy (they won't)
- Accept using your cell data at school instead of their wifi (works, but is expensive)
- Bypass it using a VM (requires moderate technical knowledge, networking skills and possibly the ability to bypass vm detection)
- Reverse engineer it and crack it to behave the way you want (requires some pretty advanced technical skills)
As such, the vast majority of people will just go ahead and install it. This is the problem with these sorts of applications...
No practical drawbacks so far, although I have found many “open resolvers” online from my home, only to realize it’s the redirection messing things up.
In which case these applications are either broken or malware.
The application needs to fix that by using DNS supplied by the OS, as everyone should do.
The DNS setting by the OS, just like the proxy settings, is a first suggestion on how to connect.
Chrome will contact 8.8.8.8 in certain circumstances and Firefox has DoH. Both can set proxy settings different from system via various means.
[0] https://dxr.mozilla.org/mozilla-release/source/modules/libpr...
[1] https://dxr.mozilla.org/mozilla-release/source/browser/app/p...
[2] https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Ent...
[3] https://support.mozilla.org/en-US/products/firefox-enterpris...
this stuff about finding all the right config files during "basic hardening" and having it just work is the stuff of armchair commenters and people who do IT/security on a well funded, sufficiently redundant team. assuming the latter would be the people in charge of school IT is hopelessly naive.
The problem with half assed work is that you still put in some effort but reap none of the rewards. You work to uninstall Firefox from dozens of computers but get exactly 0 results because now you’ll have to configure Chrome. Default installations of both browsers are perfect for home use but woefully inadequate for controlled networks.
And in the end you put in just about as much effort as changing some flags in any one of the dozens of example config files available on the internet and copying it on every machine.
- Implement a proxy to break SSL.
- Configure the browsers to disable DOH (GPO or local configuration) for as long as it's an option.
- remove all browsers because that's the solution you already have in place.
I wholeheartedly disagree with any resolution that just hides or ignores the issue especially when it's scheduled to become more or less standard.
Micro-level view: I'm a sysadmin for my Customers, my family, and some of my friends. Inevitably I will have to deal with these awful devices. So will countless other sysadmins. I'm dreading having to deal with devices that invade my users' privacy, thwart my attempts at detecting bad actors on the network, and that just generally act like the person who paid for them doesn't actually own them.
Because by making this the default, they are helping centralize the internet and greatly benefiting the entrenched powers while putting barriers to entry for the rest of us.
That would be nice in an ideal world, unfortunately most of us live in reality.
I had thought that internal networks these days would favor multicast resolution (LLMNR/mDNS), but that doesn't appear to be the case here. Admin work is not my wheelhouse, so I have no idea what standard practice is. What is the recommended setup for AD and name resolution configuration?
I don't like this one either, but often it is inherited from the past from other people and it is not going to change.
On the other hand, split-horizon DNS is going to stay with us, even if the AD domain is a subdomain of the public one. Records in the internal zone are not going to become public anytime soon.
On the other of the common problems: I assume there is no way to blackhole existing, public records, other than extension ala uBlock/Adblock?
If you insist on using a third party resolver for name resolution they will have knowledge of your queries no matter what the protocol. Doing it over tcp and http is not any better, or worse, than doing it over udp. This is something you have to opt in to.
Does it come turned off by default?
If a network operator can change DNS, then the ISP, network hops, or a malicious twin AP can as well.
The network operator provides an IP through the DHCP response, which also includes proper DNS-settings for that network.
How is this malicious or replacing “your” DNS? The DNS belongs to the network.
> The DNS belongs to the network.
This is the question - should the network really be able to tell the client what IP corresponds with a DNS name? if no, then there's no good solution to blocking websites where you can't install things on the client's device. Meanwhile, if you say yes, then you must also say yes to ISPs being able to tell the client what IP corresponds to a DNS name. The only solution in an enterprise context is to buy new hardware (or install a software update if Cisco is feeling benevolent) that runs a DoH server. In a school-bocking-porn context, you could ban the biggest offenders via IP (mindgeek sites have a dedicated IP space I think, and you could cron your own DNS lookups for other non-CDN sites) and use SNI whitelist until eSNI is added to iOS.
The user of the OS can then set their own DNS. If applications just ignore this and use their own it takes away power from the user. Sure Firefox lets you turn it off, but a lot of people won’t bother.
Doing it properly would involve securing the system, once. This could be easily done by installing a DoH stub resolver service and then pointing the system config to localhost.
Currently DoH or DoT are only used and designed with the goal[0] to secure stub resolver <-> recursive resolver traffic. Someone has to operate that recursive resolver and you have to trust them. So you only shift the problem from having to trust your ISP to having to trust cloudflare/google/etc.
Dnscurve is intended to secure the recursive resolver <-> authoritative traffic, which means you don't have to rely on another party to secure your traffic. I guess dns over dtls could in principle fill the same role, albeit with more overhead.
It sounds like DNSCurve might be easier to configure and setup from your perspective?
What I am missing is a way to secure the traffic from the recursive resolver to all the authoritative name servers in the world, i.e. to achieve end-to-end encryption for lookups.
Yes I am aware that this would require dnscurve support in most authoritative servers around the world and that the rollout would take many years. But DoH provides a false sense of security, to me it's a distraction that just shifts us from ISPs saying "trust us" to google&co doing it.
There's so much that Mozilla could do structurally, but they are terrified of rocking the boat or disrupting their corporate underwriters.
Just like earlier today, with their anti malicious javascript features[1]; they could look into empowering the users and changing the structure of how js is run in the browser. But that might threaten advertisers, so instead they opted for a clumsly blacklisting solution instead.
If you want an accurate heuristic for predicting Mozilla's behavior, just ask "What would Google want?". It may not be Google in particular that these decisions benefit, but they absolutely benefit those entities that are locking down and siloing the internet.
You trust your device and the entity, and the entity trusts the infrastructure and services they're using. Everything else is the enemy. So moving the barrier to a CDN which the entity trusts is actually an improvement over intermediate ISPs which neither of you trust.
For BYOD, I don't know what you're gonna do. Many students have smartphones too (some with tethering), and you can't control what they look at on those either. Plus, even if the school could somehow magically lock everything down 100% within the confines of the school building, the students can still get access to whatever at home, or using coffeeshop WiFi, or whatever.
That's fine, these are not school responsibility. Once the parents complain, you can redirect them to their home or coffeeshop.
5 is not the default, so if you set it it will get stored in user.js and then even if the default changes the value will remain 5.
Perhaps because he's describing 2 different situations. One where "some schools" are removing Firefox, and one where it's not an option for him because of BYOD. Uninstalling Firefox is exactly the solution he can't apply. So I still maintain that the other schools that fully control the clients could have applied a proper fix faster and cheaper than any uninstall. It's one line in a config file [0], already linked above.
All your replies are gratuitously aggressive and insulting. That's not a good way to contradict my solution that works, is simpler and more future proof than uninstalling browsers with DOH.
Eventually all browsers will have DOH, you can't uninstall them all. And leaving a browser unmanaged and at the mercy of a student is not an option since requiring 2 extra clicks to bypass the filtering isn't a solution. You need some form of management either way.
I already gave you a solution that's better than removing the browser and "cheaper" than having to manage Chrome with GPOs (not a high bar). Insults won't change that.
[0] https://dxr.mozilla.org/mozilla-release/source/modules/libpr...
of course, you would need to do more in chrome (and windows/osx/ubuntu generally) to stop traffic to a site if a student knows what they're doing. that's not the point. the point is: we have this control in place. we've agreed it's working well enough. people can bypass the control simply by using firefox. to avoid adding overhead, we ditch firefox (for now). it's that simple.
as for future-proofing, that's a luxury. ...and part of why it's a luxury is that some goals ("make all traffic to any porn sites impossible on our school network") just aren't going to be met by budget IT.
re: BYOD, for that i go over to the armchair tech purist side i'm afraid, and just say "well, you allow that, so you need to get over that they can use VPNs and stuff. you're not DOJ or some wealthy corporation with important IP assets and equally 'important' VIP execs that insist on bringing their OSX 10.6 MBP to work. you don't get to have all the cool controls that might allow BYOD. sorry."
...which reinforces my point about how people actually doing this and people speculating about it tend to respond to issues like this.
I take it you assume students are not creative enough to get the exact same result with Chrome? Because it is perfectly possible to do it. Unless of course you take steps to prevent that in Chrome. One way or another you either put in the work or the users will end up doing whatever they please. After configuring the OS doing the same for the browser is a relatively small step.
i'm belaboring this point now, but people who actually do this stuff know that you can't just throw up a GPO to fiddle with chrome settings and expect everything to work. this culture of "power users" thinking they know the best course of action for every situation in IT (and it's always "that thing i Put In The Work to do when i was tailoring my own system") is really silly.
I'm not so convinced that the authenticity of the data you're conferring to the DNSCurve network is conferring greater security than DNSSEC and TLS. I'm not arguing one is better than the other, but I kinda see it as a wash.
Both DNSSEC and DNSCurve are basically dead-letter standards at this point; interestingly, the stake through both their hearts is DNS over TLS or HTTPS, but for different reasons: DNSCurve, because DoTLS essentially replaces the entire protocol, and DNSSEC because DoTLS reveals (through its rapid adoption, among other things) how marginal DNSSEC's contribution actually is.
[0] https://tools.ietf.org/html/rfc8094#section-1 [1] https://tools.ietf.org/html/rfc7858.html
It would be nice if these apps could detect whether the system is using DoH and only fall back to their own DoH resolver in the case they're using "legacy" DNS.
If I want to use DoH when sending DNS queries to the outside world, I can setup my own forwarder to forward DNS queries via DoH.
To my knowledge none. Nobody is doing this, because it subverts how DNS is supposed to operate.
> It would be nice if these apps could detect whether the system is using DoH and only fall back to their own DoH resolver in the case they're using "legacy" DNS.
Yeah. Good luck diagnosing that when something stops working as expected.
Huh? Of course people do this, it's a standard way to do DNS that improves over older DNS wire protocols by offering better security properties. It's unfortunate that we had to involve HTTP in this, but needs must.
For example you can drop in an NSS replacement that uses DoH instead of conventional DNS for all your glibc software, or you can get software from a variety of sources that runs on UDP port 53 of your local machine like a normal DNS relay but uses DoH to someone trustworthy to deliver.
I would go even further: Any app trying to bypass the system-level network settings (like with DoH) should be considered malicious and possibly malware.
This is what spam-bots used to do back in the days. Now let’s add Firefox to the list.
This is my point of view precisely.
* network.trr.mode can be set to 0 (disabled), 1 (race native vs TRR), 2 (TRR first, OS DNS as fallback), 3 (TRR only), 4 (run native and TRR in parallel but use native results, save TRR timings for telemetry), or 5 (off by choice)
* network.trr.uri configures which DoH endpoint is queried
Firefox does maintain a DNS cache, even if you use the native DNS resolver. You can view the cache at about:networking#dns.
They were better off uninstalling Chrome. Firefox at least can be controlled with a config file and a script to do bulk copy, Chrome wants GPOs and without lockdown you have a ton of extensions in the store to make your DNS filtering redundant. I believe the latter is the better option but if a config file is beyond the possibilities of the school admin I expect their browsers to be fully unmanaged and at the mercy of the user. It can't be both ways.
I appreciate that you finally confirm what I said from the beginning: It is a half assed job (because doing it properly "is a luxury"). Uninstalling just kicks the problem down the road and lets "future you" deal with it a few days or weeks later.
> an app which is out of the box functionality
Begs the question why put in effort to install then uninstall it when there was no need for either. I'm not in their head but one thing's for sure, your explanation relies on conflicting argumentation. We're talking about a hypothetical Schrödinger's admin that at the same time both has and hasn't got the resources to do the work.
Cheerio.
The point is stopping them downloading this stuff using schools property or infrastructure. If they download it elsewhere, it is someone others problem then. If someone complains, its someone elses' fault, and the school can fingerpoint.
If they just bring it to the school, they can be disciplined, but no other steps need to be taken.
I thought we were talking about how hard it is to fix Firefox. This can be done on a budget - part of an afternoon - since it can be very easily managed with a plain old config file copied to all machines (at least until a couple of versions ago). With this gone you're left with Chrome. How would you make sure no user can use any one of the multiple options to abuse a non-managed Chrome and bypass this? Remember that your target isn't to have a browser that doesn't mess up filtering, it's to prevent students from using any (creative) means to access restricted material. And with Chrome there's one sure way to prevent those creative means. So don't answer, it will be GPOs.
And since your fix for DOH and DNS filtering is to uninstall the browser (!) when Chrome eventually implements it will make for an interesting conversation ;).
as for once chrome implements DOH, they'd cross that bridge when they came to it. it's an uphill battle, because really content filtering, of course, should not be done through browser settings (remotely managed or otherwise), nor solely through DNS. if whoever tells IT what to do in that school district is hellbent on it being impossible to browse to pornhub, they'll ultimately need a layer 7 firewall. but again, when you're on the budget, you do fastest / cheapest / most effective.
(and if we return to pure hypothetical, i would argue that dns filtering really is the best way in their case, because anyone who could bypass that--besides just using firefox--will be able to bypass better chrome config, or your firefox config change, etc, since they can just edit host file, etc etc etc)
But I don't understand the network argument. If you are perfectly fine with TLS traffic then insisting on seeing DNS traffic sounds weird to me.
At the same time, if you force TLS traffic to go through a proxy then that will immediately restore visibility of DNS as well.
I guess network operators still have to come to terms with the idea that in the future all traffic will be encrypted.
Yes, it is annoying if you can't see anything in wireshark. But plain text is just a thing of the past.
With QUIC (HTTP3) a large part of the network stack will be part of the application. So you lose that visibility as well.
Even better corps should only allow TLS that they can successfully MITM.
It's basic security. If the endpoint/host can do whatever due to lack of firewall/enforcement, then it doesn't really matter what the network operator wants.
What good is that is the browser uses their own list? Literally that's what the article is saying. Firefox will force users to use ones that break the top-down approach on how software works. If I set a DHCP option for DoH, and setup my own DoH resolver, Firefox wont care, they will jsut use their list.
This also opens up possibilities for selling positions on the trusted list, because we've seen that happen before (adblock, or the firefox Mr Robot extension.)
Firefox itself, with plays like this are trying to make a decision about the whole, when they are completely forgetting the corporate side.
So what is left is that breaking up TLS just infringes on privacy and allows for tighter control. The security aspect is laughable.
Users are angry that their internet got slower, an it creates an enormous administrative cost, because you need countless exceptions to the rules.
Most developers break out of it in a few days...
Some of your best friends, eh? The point of MITMing HTTPS in an enterprise setting is not inbound content scanning (though that's pretty useful to), it's to prevent outbound transfer of secrets/HIPAA or PII data/financial data, and it's a regulatory requirement for some industries.
Besides, the point of DoH is to move DNS into the browser, which Google also controls, to prevent pihole-like DNS-based ad blocking. Cloudflare supports it because it allows them to lock down one of the few remaining actual distributed systems powering the internet. These companies are not your friends, and you should think harder about their incentives.
So, carry on with keeping bad actors off the network and ensuring that there is sufficient capacity and resilience in the network.
More here: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?...
and Only works on Enterprise Networks for devices owned by the enterprise because the Enterprise Installs their own Root Certs on all devices that "tricks" the browsers into believing they are "google.com" not the real google.com
How so? It looks to me like it makes it easier for bad actors to take advantage of my network, by making it harder to detect and block DNS lookups.
Preventing cell phone calls could have dire consequences in an emergency, and stopping kids from looking at porn doesn't remotely merit taking that risk.
To your point, there are certainly countries and jurisdictions that do not permit blocking RF or have strict exceptions.
In the US, local statutes and AUPs don't enter into it. This is federal law. You're right, there have been a number of organizations that have done this -- and enough of them have been fined for it that the number is much smaller than it used to be.
It won't be when it's functionally impossible, which seems to be the point.
You do see the light at the end of the tunnel, right? Browsers shipping their own unmodifiable CA stores and disrespecting 3rd-party CAs signatures for public DNS names.
With desktop OSes, it is no problem.
With mobiles, traditionally, if you enrolled a custom CA root onto Android device, the user would be nagged ("You network may be monitored").
Malware can go further, and just use it's own root, without any ability to enroll your custom one. I see this as a default with any IoT or embedded devices, so that will make much more difficult to say "no custom CA, no internet access".
Are you going to change the settings manually after each connection in different network? Most people won't. We already have an automation for that, called DHCP, setting up network specific config system-wide... which Mozilla decided to ignore.
But I want all the devices and apps to use whatever the local network tells them. I don't want to reconfigure the browser every time I connect at home/work/customer place/etc.
P.S. My ISP's DNS doesn't lie. Maybe you should vote with your money and choose better.
Also, I disagree that denying the lookup of certain domain names is abusing DNS. If I were running a DNS server that was being used by the public, or that was being used by downstream DNS servers, that would be different.
Also, I'm not aware of a method that can accomplish the sort of coverage that blocking DNS lookups can. If you have an alternative, I'd be genuinely interested in hearing about it.
Agreed with you there, I'm not saying that multilayered security is a bad thing.
What I'm saying is that right now, in terms of easy and accessible DNS privacy, we have 0 layers. Don't you think it might be worth sacrificing this one partial, incomplete access control solution in favour of solving that?
Without cooperation of the device, that is indistinguishable from that of a bad actor.
You can get what you want by owning the device and requiring it to cooperate (ie with controlled software or a certificate to allow monitoring / blocking).
Sure, if you have a router and know how to configure it. The second requirement excludes the vast majority of non-tech-savvy users, even though they are also harmed by lying or data-collecting DNS resolvers and likely would not consent to them if asked. (The first requirement additionally excludes phones and other devices directly connected to a mobile network; of course, you can generally configure the devices themselves to use a different DNS server, but it may be annoying if you have a lot of them. More convenient if devices already default to the option that protects your privacy, i.e. DoH.)
> P.S. My ISP's DNS doesn't lie. Maybe you should vote with your money and choose better.
Even if it doesn’t lie, does it log requests and sell that data? Are you sure?
Anyway, in many locations including most of the US, there’s no meaningful choice available among wireline ISPs.
This is pure genius! Why didn't I think of this? /sarcasm
That works really well in an area where Comcast or some other scumcorp has bought out, lobbied out or driven out the other ISPs.
There is exactly one choice for an ISP where I live.
"You can configure your router, a client device, to use whatever DNS server you want in defiance of your ISP, a network operator."
Which one do you want?
Mozilla or other app vendors are not.
No dichotomy there.
In a crazy world where internally Firefox ran a small IP network for each tab and routed traffic between them for IPC would it suddenly be okay for Firefox to override DNS? Why or why not?
If you modify your router settings, it's you. You decided that you are not going to honor ISP suggested defaults, and it is up to you to assess costs/benefits and pick the right choice.
If Firefox overrides your settings, it means someone else does the decision about your tools. If that someone else makes it difficult to automate changing the default (e.g. ignoring DHCP; if you want, you can ignore DHCP at the system level, but this is not a decision an app should take), it means, that this someone else doesn't have good intentions towards you. Someone else decided what's "best" for you.
I agree that DNS should be a system level concern rather than an app-level concern but in the real world browsers want to protect their users' privacy and the OS they run on doesn't do that. If every app went out and started using app-level DNS then it might get annoying but browsers are particularly privacy and security sensitive.
With this change almost everyone (i.e. people who don't mess with their OS setting and don't know or care what DNS is) are markedly better off.