As a resident of a country whose government and ISPs heavily and habitually censor the Internet for political reasons, I for one truly appreciate Firefox's DoH. They should also enable 'network.security.esni.enabled' by default because the censors here have upgraded from DNS to SNI-based blocking. I get it that better solutions are possible, but got to teach people to first walk before teaching them to run. AFAIK, Chrome still doesn't support this kind of simple user-friendly privacy options for the average non-technical user.
Chrome uses opportunistic DoT - it uses your system configured resolver, and if it supports DoT, it will use DoT, if not, it will fall back to 53/udp.
I like Chrome's approach much better; it doesn't force you to statically configure DNS server - it is a PITA, especially when roamining and you want to resolve hostnames available only in local networks.
> ...it is a PITA, especially when roamining and you want to resolve hostnames available only in local networks.
Not really.
If you're not blackholing traffic at the dns-layer via DoH, set Firefox's trr.mode to 2. Per documentation, at the cost of additional latency incurred, system-level / network-level resolvers should pick up the slack, provided they've been set as appropriate via DHCP or otherwise.
If I sit any family member down in front of this comment, their eyes would glaze over. Not only is what you mention a PITA, it's impossible for most people.
I'm a programmer and I have no idea what OPs comment means. I keep meaning to learn about networking stuff, but there is always so many other things to learn and since I don't work with devops or networking stuff it hasn't really been a priority.
Agreed. Just looked up about trr nonsense and found this 'setting':
> network.trr.excluded-domains
> Comma separated list of domain names to be resolved using the native resolver instead of TRR. Users may add domains they wish to exclude from TRR to this pref. This pref can be used to make /etc/hosts works with DNS over HTTPS in Firefox. Setting network.trr.excluded-domains to include host names from /etc/hosts will make them fall back to platform DNS, which will use the rules in /etc/hosts.
So, rather than using the hosts file, network admins & devs now have to specify 'special sauce' in FF too?
I'm not buying DoH for this reason alone, because it throws out a lot of legacy (albeit always regarded as hokey) for no good reason. If FFox is doing it's own DNS stuff is MUST (at least) do hosts file resolution, imho. Otherwise it leaks names, which kinda defeats one of the main the purposes of DoH: which is to maintain critical privacy in places where it's being abused.
You're not alone. That said, I highly recommend reading and referencing "High Performance Browser Networking" by Ilya Grigorik^1, it's accessible, detailed, accurate, and useful in the extreme.
AFAIK, when one turns on DoH, Firefox's trr.mode defaults to 2. And that's the default behaviour most would want except for the ones using pi-hole et al.
In general, yes, that solves the problem for local domains. But anyone who needs to do anything at all complicated is going to have trouble with this, not just Pi-Hole users.
For example, take your average John Doe who uses Firefox. Not particularly technically competent. A new version of Firefox comes out, and all the Archive.is domains break. Who does he blame for that, and how does he solve the problem?
What's happening behind the scenes is that Firefox switched his DNS address on him without warning. And Cloudflare (the DNS endpoint used by Firefox by default) returns incorrect IP addresses for the Archive.is domains (because the admin of these domains returns fake addresses to Cloudflare from their authoritative DNS server).
Most people are using DNS provided by their ISP, so they haven't seen this problem before. I know about the problem, and my resolver (Unbound) is set to use Cloudflare over TLS for most requests, but sends Archive.is domains to Google's DNS instead. This solves the problem for me. Firefox switching to Cloudflare by default not only breaks sites like this for the average user, it even breaks my workaround that fixes the problem.
(I can't currently reproduce the problem, so maybe Archive.is caved and started sending working IP addresses. But it's the sort of problem that can happen when you start messing around with DNS. Your users will blame you if a site doesn't load in your browser, but works in other ones.)
Nah, the lesson is that users are going to blame you when you make low level arbitrary changes that break things when they're not capable of knowing about and fixing the technical problems that arise. The fact that a change might accidentally fix problems sometimes isn't a counter example to that general principle.
Even when the possibility of things getting fixed is substantially more likely than the possibility of things getting broken?
By default Firefox will fall back to the network resolver if DoH can't get the results, so the only way that a situation like this could happen is if someone purposely sabotages the DoH results like with archive.is.
Furthermore, what you are saying could basically be used to rationalize putting any kind of potentially breaking change behind an off-by-default configurable. Do you think the web would be the sophisticated application platform it is today if browser vendors actually had that philosophy? Would that actually be better for John Doe, to make them have to learn about the technical aspects of every new web technology before they are able to take advantage of them?
That's a bit unfair, because this comment was obviously not addressed to the mere mortal. For you family member, a "how to" with a lot of screenshots and red arrows is probably more appropriate.
Considering the amount of people using library or Starbucks internet that needs you to use the local DNS (at least once you initially connect), maybe #2 should be the default? Or is there some risk in doing so?
Half of your comment doesn't make any sense but for the rest of it, its just incorrect. The change in firefox hasn't broken anything, security is certainly improved in combination with other efforts like encrypted SNI. And yes, your dns requests always leave your lan at least once. You can run your own DNS server locally but that dns server has to ask other servers for the data since it can't store a local copy of the entire dns system. A local dns server is just a cache but with a few users its likely not doing any more than your browser cache.
DoH breaks anything that is going on in your BIND or NSD server. It bypasses them, it has broken that. If it does DNS first, then if that fails does /etc/hosts, its broken that too.
If I, or my company, or ISP has anything special in hosts or DNS, e.g. load balancing, name mapping, breaking facebook.com, things like that get bypassed.
DoH over HTTPS is slower than a lookup to /etc/hosts, and probably slower than a lookup to a locally cached DNS resolver.
Security is not improved by FireFox bypassing my network admins DNS rules.
Most DNS queries do not go over the Internet, unless you have DoH or have set special DNS servers. My ISP provides IP access to the Internet and DNS, like almost all ISPs. It not to do with local caching (which does add security), if I query foo.com that query goes to my ISP, not via the Internet, my ISP knows I asked for foo.com and then then the routes my IP packets there.
My ISP has to lookup DNS on the Internet to resolve them if it is not in caches but that lookup is not associated to me.
When I connect to a corporate network all my DNS goes over VPN if any information is required from the Internet again that is not associated to me.
Cloudflare might be running a more secure DNS resolver at the other end than my ISP, but it might not, its rules have to apply to the whole world so they cannot be tuned for me and my security preferences.
After DoH, all DNS goes over the Internet, even quires that eventually are resolved locally. Cloudflare now know I'm going to foo.com and so does my ISP, or VPN provider, I don't see how security has improved. Its just sending information to a commercial partner of Mozilla's in addition to my ISP. Some informationits getting that before my ISP did not get.
Plus HTTPS is not infallible.
DoH is more secure than DNS in plain text over the Internet, but that is very rarely the case.
DNS is also not a significant risk to browser users. I have never had a DNS response faked, to any HTTPS site it would not work, so why bother.
There isn't much risk, its not more secure, and it breaks stuff.
I've noticed some problems with eSNI so far unfortunately. Some domains like discordapp.com have some access points with eSNI enabled and some without, so when clients access the ones without eSNI, they believe that they are under attack. I cannot wait for it to be finished and implemented though, it would be a huge benefit for the privacy of millions.
TCP-over-DNS, together with the draft RFC for encrypted resolver to authoritative communication, altolows for more end-to-end style encryption. Clients could do their own secure resolving without relying on a central service.
The features are available everywhere to everybody but are not enabled by default. The only difference for US users is that they're enabled by default.
Just 2-3 years ago, normal DNS to CloudFlare or Google DNS were enough to bypass my ISP's DNS redirection. Then those got disabled and while I switched to DoH, many others switched to paid VPNs. Now they've moved up to SNI blocking. They may catch on to the trend and block DoH IPs too if DoH becomes popular.
Won't help if cloudflare sticks the resolver on the same IP range as regular cloudflare sites. Countries would have to choose to block most of the internet.
If the ISP (or Nation) is willing to block google or cloudflare IP-ranges then you will have to be a moving target.
Using tor and similar. For normal shitty ISPs thats not an option
Cloudflare and Google's dns resolvers got a lot of adoption bc they provided a way for normal people to get around censorship, but they're inherently censorable bc they're run by centralized companies. There are new initiatives aiming to create a distributed dns layer which are promising like https://handshake.org.
Security is not binary, it's a spectrum based on cost. It's the same for censorship-resistance. If Handshake increases the cost of internet censorship for every country in the world, then it will have succeeded even if it's still possible for countries like China to censor it.
> Cloudflare does not block or filter content through the Cloudflare Resolver for Firefox. As part of its agreement with Mozilla, Cloudflare is providing only direct DNS resolution. If Cloudflare were to receive written requests from law enforcement and government agencies to block access to domains or content through the Cloudflare resolver for Firefox, Cloudflare would, in consultation with Mozilla, exhaust our legal remedies before complying with such a request. We also commit to documenting any government request to block access in our semi-annual transparency report, unless legally prohibited from doing so.
I'm so sad to see Mozilla move forward with this massive attack on user privacy.
Firefox DoH is snake oil, plain and simple. It sends all the users DNS queries to Cloudflare, adding a new party which can surveil the user's traffic (and can be legally compelled to do so and not disclose this fact)-- providing a convenient choke point to save spies and hackers the trouble and exposure of extracting the data from tens of thousands of individual ISPs.
Simultaneously, it does not protect the user from monitoring by their ISP or parties situated there because the user's destination IPs remain unencrypted, as well as the hostnames via SNI (for cases of shared hosting, e.g. on cloudflare, where the IP alone wouldn't be enough).
At the moment you can disable this across your whole lan by blocking traffic to 104.16.248.249, 104.16.249.249, 2606:4700::6810:f8f9, and 2606:4700::6810:f9f9 and by DNS blackholing use-application-dns.net and cloudflare-dns.com.
iptables -t raw -A PREROUTING -d 104.16.248.249 -j DROP
iptables -t raw -A PREROUTING -d 104.16.249.249 -j DROP
ip6tables -t raw -A PREROUTING -d 2606:4700::6810:f8f9 -j DROP
ip6tables -t raw -A PREROUTING -d 2606:4700::6810:f9f9 -j DROP
And if you're using bind:
zone "use-application-dns.net" {
type master;
file "/etc/bind/db.empty";
};
zone "cloudflare-dns.com" {
type master;
file "/etc/bind/db.empty";
};
Or unbound:
local-zone: "use-application-dns.net" static
local-zone: "cloudflare-dns.com" static
But there is no guarantee that these mitigations will continue to work.
[Edit: Aside, this comment and many/most(?) comments on this thread were moved from a more recent thread with a headline "Firefox turns on DoH as default for US users". The new title which omits the on-as-default, is kinda burying the lead.]
Your ISP is literally selling this information right now in the US. What are you even talking about? Use google if you don't like CF, or just disable it!
Do a little threat modeling here please. Let's say CF sells this data, what do they know about you other than your IP and the sites you visit? While your ISP,employer,school,etc... Can tie that activity to you as a person. Being compelled legally? I did not know privacy meant breaking laws, suddenly law enforcement can't do the same thing with your ISP dns?
This is not adding a new party that can surveil you, this is reducing risk by separating who can see your DNS from who can see your traffic. The idea is to have eSNI ubiquity to where TLS traffic will conceal the sites you visit while DoH will conceal the traffic metadata. Oh, and beauty of DoH: you can run it through a web proxy, and if you have alot of users behind a NAT it becomes very hard to pin point which actual machine generated the DNS lookup.
Sorry for channeling the dude here but that is just, like your opinion man.
I think many of the critical voices now are coming from the EU. We have data protection laws. The ISP can't just sell browsing data. That has been illegal since before we had data protection laws, that is actually legally the same as opening other people's letters and reading them. So ... different threat model over here.
I am always using the US-EN Firefox version because frankly why would I use translated software when I can understand and use the original.
I hope you can see how it might be of concert to me whether Mozilla decides to give my browsing data to Cloudflare, whom I have about as much reason to trust as GCHQ or the NSA.
EU ISPs may not sell your data for advertising purposes but they do log your traffic in order to report it to local security agencies.
I understand that in the EU we enjoy stronger privacy laws, however trusting your ISP, given they have the ability to link your traffic to your real name and address, is incredibly naive.
For protecting privacy we need both laws and technology.
First of all we are not talking about the trustworthiness of VPNs, that's a separate discussion entirely. And no, I don't trust my ISP more than I trust my VPN, but I understand your mistrust as VPNs are indeed not so private as they are marketed. But imo this is throwing the baby with the bathwater.
Go to Germany, download a movie either from the Pirate Bay or see one from one of the many illegal websites streaming content and prepare for a letter (delivered to your home address) with a huge fine and a legal threat within a month.
Not that I'm a huge fan of pirating content, even if some cases like Sci-Hub have the moral high grown, but this goes to show just how trustworthy an ISP is, in an EU country with some of the best privacy laws ... and in such cases a VPN is absolutely mandatory.
---
DoH hides your DNS queries — if you visit an HTTPS website, the traffic might be protected via HTTPS, but the domain name is clearly seen.
Of course, the ISP still sees the IP you're communicating with, but due to SNI and industry practices nowadays of putting websites behind CDNs, IPs don't necessarily reveal the website you're communicating with.
DoH also makes it harder for ISPs to block or redirect your access to certain websites. For instance it makes it harder to block Pirate Bay based on the whims of your local government. Now certainly Cloudflare can also be compelled to block websites like Pirate Bay, but the DoH service you're communicating with is customizable, you can pick whatever service you want and just like VPNs, I predict there will be plenty of privacy respecting services to choose from.
And DoH is not foolproof, it doesn't solve all of our privacy needs, it's just a piece of the puzzle, but a necessary one.
> I predict there will be plenty of privacy respecting services to choose from.
Why, where is the money in there ?
Sure there might be some, but many ?
Call me cynic but I don't think google(one of the biggest public DNS servers atm) or clodflare(probably second biggest) are providing this service out of goodness of their harts.
If you worry about DNS that much, running your own is not that hard (I am running one at home* , and one at the place I work).
I don't know why Google and Cloudflare provide this service and I don't really care, because it's irrelevant.
DoH is first of all a protocol. If you run your own DNS resolver at home, surely you'll be able to run your own DoH server too.
Also your requests will no longer be sent in clear text, which means that a Wifi administrator at your local coffee shop won't be able to see your queries and responses, which with the regular DNS protocol are in cleartext, in which case your home DNS server does not help — unless you're on your own network in full control of your router, or run your own VPN, communications with your home DNS resolver are just as vulnerable.
The value of something like DoH is clear, regardless of the motivation that Cloudflare and Google have for providing such a service for free.
---
Speaking of which, accessing pirated content is not the only case I worry about — another problem I have with my ISP is that they serve me a 404 Not Found page filled with ads on domains that aren't available. This is in an EU country.
Also back when HTTPS wasn't forced on Google, the searches were logged and people were automatically flagged for problematic queries and then potentially monitored for years. One of the topics that triggered automatic flagging was child sexual abuse — I know because I helped a local campaign, building an awareness website, etc, only to be informed of such practices by an acquaintance working for our internal security agency.
And while today this may happen for legitimate reasons, tomorrow it might happen for people criticizing the government. Look no further than countries like Turkey or Hungary.
Personally, coming from communism, I fear the nanny state more than I fear big companies from other countries.
> Personally, coming from communism, I fear the nanny state more than I fear big companies from other countries.
I am from Slovenia and I know exactly what you mean, and agree 100% with that.
I just think that in the end POE is worse, since I think it will result in concentration of something that was widespread (plenty of small ISP's and providers), into few
bigger and easier to backdoor providers. So it will be easier to monitor then before.
And I don't think think that western democracies and "democracies" will just throw in their towel.
I trust Cloudlfare and Google less than I trust my ISP, if nothing else their budget (and competence, and reach) is much lower(isp's).
I mean gmail and outlook are much more competently run than most ISP's and businesses ran their mail servers. I am afraid something similar can happen here.
> DoH is first of all a protocol. If you run your own DNS resolver at home, surely you'll be able to run your own DoH server too.
Packets never leave local network. The advantage of DoH is that it's over https, so if you don't control your firewall you can still use it.
But if you control your own network, DoH is not that useful, since you still have to support old DNS for all the applications and devices that don't support DOH.
If someone can listen on your LAN you have bigger problems than someone being able to intercept your DNS queries.
Not saying there are no advantages, it just isn't a priority.
I want the legal policy to be based on where I use it from, not which language I download. As a .nl citizen I personally hate language localization, set my locale to en_US.UTF-8, and always ensure I download the international versions of my browser. I would expect at the very least the legal policy to be tailored towards where I download it from, but preferably where I use it from.
> I am always using the US-EN Firefox version because frankly why would I use translated software when I can understand and use the original.
This is maybe not the topic of discussion, but the argument is that your computer is your tool, and the computer should speak your language and adapt itself to you, and not the other way around. For this reason I like and prefer software that speaks my native language! However, I don't have patience for bad translations, and in those cases I'll avoid the translated apps. Not a problem for Firefox!
It's worse than that. Some words did not exist in the target language (the computers are relatively new compared to the age of the language) so they had to be created. Nothing is more annoying than to search for words which make no sense.
Why do you think english is any different? Silly words were created for new concepts in computing (as in other fields) in English too.
You just don't notice how silly all the new words are (like bit and byte, and "gigaflop" and so on) because english is a prestige language and that it is a foreign language.
I don't get how that's a swipe, it is not a rhetorical question, my intent there is to literally ask what he's talking about given the arguments made. I did not attack the commenter personally,"brigade" or an ad-hominem argument. I think you might be misunderstandig our conversation here, this being a text medium it is hard to comminicate tone and body language. It's not uncommon for me to say a phrase like in technical arguments with people I get along with very well. This is a technical discourse not a interpersonal one, my disagreement is with the supposed factual statements not the person as such how can it be a swipe against them?
That said, I will avoid that specific phrase on this site as you asked.
It's easy to get hung up on specific words, so it might be easier to consider meanings. What is the meaning of the phrase "What are you even talking about?" Is it a question? If so, what answer were you hoping for?
If I take you at your word that it's not rhetorical, then I could replace your question with "what do you mean?" – however, if you don't know what the poster means, why does the rest of the comment continue as if you understood them perfectly?
The more plausible interpretation of "what are you even talking about?" is "you are spouting nonsense". Yes, your wording is more polite, but the meaning is the same. The only way a polite insult isn't an insult is if you assume the person you're insulting doesn't understand it. Kinda makes it two insults, really.
All discourse is interpersonal, and how you disagree with someone's statements has interpersonal implications. I think your argument misses the point. I also think your argument is disingenuous and avoids engaging with substance in order to project misunderstanding onto the person trying to help you.
Both of those are opinions about your statements. Which do you think best exemplifies the following?
> Be kind. Don't be snarky. Comments should get more thoughtful and substantive, not less, as a topic gets more divisive. Have curious conversation; don't cross-examine.
It's not rhetorical and it is not literal either. A rephrase can be "what you are saying makes no sense for the reasons I am about to lay out and I would like it if you can address my points below, based on my understanding the argumets you made lack basic coherency, please tell me what you think of my counter-argument".
If this was a work email in a super-uptight place I would say something like that. Had I known that simple phrase I use all the time would be so controversial I would have avoided it or rephrased.
You chose to question my motives and assume the likely explanation is that I am atracking the person instead of their are argument. I am insinuating that their argument sounds ridiculous but I am not implying that as a fault of their intellect or personality but a lack of perspective where sharing my perspective might help them change an opinion.
I will not defend my personality and motives being questioned when I made no attempt to do so, I also did not the attack the person themselves in anyway. You should not assume malice. I think @dang saw me break rules in the past over one of the politcally charged threads and assumed it was in my personality. Feel free to review my post history on technical topics like this, I make best effort to avoid ad-hominem or anything resembling an insult. Presumption of malice itself is unfair.
I have nothing to gain by attacking anyone. And even if I did, you should look at the context od what I said after that phrase to find out what my intent was. If I don't promote myself or say anything against the person why are you assuming malice?
What about when I said "please try some threat modeling here" is that being snarky as well? It can be if you assume malice. I hope no such assumptions are made.
Either way, I did make a mistake: after years on HN, I keep forgeting that it is to be treates like a corporate/work environment. Two friends using my ever so controversial phrase would not assume malice or police for snarkiness, but two coworkers or paries of a business meeting/engagement would.
I will be careful to be more aware of the environment.
Oh, and not all discourse is interpersonal. It is done interpersonally but the subject of the discourse is does not have to be the other party themselves,their intellect or character (and was not the case in my response -- very obviously)
A polite way to say this would be "Can you clarify what your concern is?" or "Can you clarify what you're referring to?". The original phrase drips with disdain. If that's not the intended sentiment, then well, that's a challenge of conveying emotions in text. You could always include an emoji to better convey the meaning :-)
Some phrases come with a built-in sentiment that people will assume exists unless it's overridden.
A rephrase would be "what you are saying makes no sense at all" I think that can equally be misunderstood. It does drip of disdain, you are not misunderstanding that part, you (and @dang) are misunderstaning the subject of this disdain which is the perceieved lack of logical coherence on my end. You're taking it as if I meant that if I am right and the other person is wrong, their knowledge or intellect should be discredited, hence why dang said it was a swipe. To me, it simply means (if I am right, which may not be the case) they lacked the perspective which I laid out as an argument afterwards. The purpose of the discord is so we gain new perspectives that change our understandings and opinions on the subject matter. I don't even remember the nick of the person I replied to, and I made sure that my identity is not visible on HN (outside of correlations people can make),I have absolutely no reason to one up anyone.
I still maintain it was clearly not a swipe purely due to the fact that I made no attempts to attack the persons personality or intellect or to promote my own, as such my intellectual honesty and purity of intent should be given the benefit of the doubt.
I think it's a good call out to keep in mind the guidelines, but technically the original comment also breaks guidelines.
Two wrongs don't make a right, but I would suggest trying to avoid the appearance of personal bias when calling out guidelines infractions on a comment without also calling out infractions within the context equally.
I don't see how the GP comment broke the site guidelines. "Snake oil" is close to name-calling, but I don't think it's really over the line, and if we started moderating HN comments for that kind of thing, there would be a huge backlash from the community. Is there something else that I missed?
These things are matters of degree in any case, and "what are you even talking about" is clear cut.
> Don't be snarky. Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.
The original comment had equally strong phrasing on what amounts to an informed opinion:
> I'm so sad to see Mozilla move forward with this massive attack on user privacy.
The insinuation that this is an attack on user privacy is a bit of an escalation in description. In truth much of the following information describes a potential threat to user privacy, for it to be an attack one would have to provide evidence of intent.
> Firefox DoH is snake oil, plain and simple.
I would argue this statement could be construed as snarky (at least that is how I interpreted it).
Generally speaking, I don't consider myself an expert, but I do think I have a more informed opinion than most (and no doubt many HN readers have even better informed opinions than my own). And while I do see the merits behind the points raised in the original comment, I do think it could have been presented better.
Person a: I like the blue stuff in oranges
Person b: what are you even talking about? Oranges do not have a blue inside.
Now what is a swipe about this or breaking a guidline. It did give the impression ( to me at least) as if I was being picked on. But I think in reality you probably misunderstood the tone and intent. Of course this is just my opinion, what you say is the law here and I intend to abide.
In this case the phrase was one that commonly communicates dismissiveness, which is why I interpreted you the way I did. If you read the guidelines it's clear that (to take your example) such a reply can be shortened to "Oranges do not have a blue inside".
However: no harm done! I appreciate your reply and your intention.
It wasn't my intention to make an inflammatory comment.
My statement was strongly worded, but it is my informed opinion as a subject matter expert: As someone who worked in ISP networking for over a decade, worked at Mozilla, and work on network protocol, I feel that I'm entitled to have a strongly stated opinion and I believe I substantiated it in my post. I'm also happy to have a polite discussion justifying it further.
I'm glad your intention was not malignant! I didn't mean to imply it was, truthfully I was just trying to also contribute to keeping discourse civil.
See my comment above about specific things that (I personally think) could have been phrased a bit better; I am not saying you're comment was unhelpful or deserves reprimand. Just wanted to point out to the comment(er) that both comments had aspects that could have been phrased a bit better and chastising one is not as helpful to improving discourse as providing complete feedback in the interest of being fair.
Disclaimer: I deleted a previous comment because on re-reading I think I meandered a bit and thought I could do better.
> Your ISP is literally selling this information right now
No, mine is not.
> Use google if you don't like CF
Google is no better.
> or just disable it!
It is never okay to hijack my DNS lookups. Posting a note someplace about how it can be restored does not change the fact that you hijacked it, and does not make it okay.
> This is not adding a new party that can surveil you
Given that the DoH provider is a new party with which most of my requests had no contact before, that is an absurd claim.
> this is reducing risk by separating who can see your DNS from who can see your traffic.
No, it is not. My ISP can still see the domain names of sites I visit, via both SNI and OCSP. They can also deduce the same information in most cases, via address correlation. (Thankfully, I chose an ISP that respects privacy.)
This change quietly hands my lookups over to another party as well. If I hadn't noticed the announcement, or didn't have enough technical knowledge to fully understand and revert the change before it went live, my lookups would be pwned.
> The idea is to have eSNI ubiquity to where TLS traffic will conceal the sites you visit
I don't care what your idea is for the future. It doesn't exist today, so is not relevant to what you have done today.
(And even if it did, it would not excuse hijacking my DNS lookups.)
They're not doing it in secret. Use a different browser if you don't like it, or fork it.
Mozilla have made a value judgement that DoH is more useful to end users than the supposed privacy loss. You're free to disagree, but neither of you is objectively correct.
> They're not doing it in secret. Use a different browser if you don't like it, or fork it.
They are not doing it in plain sight either.
> Mozilla have made a value judgement that DoH is more useful to end users than the supposed privacy loss. You're free to disagree, but neither of you is objectively correct.
Mozilla made a lot of "value judgement" lately just like Chrome.
That's why i try to switch to seamonkey.
Seems like this is where things are going. None of the main browsers respect users enough today to the point that they might not even stay usable without forking.
They see the SNI but not the host. eSNI would help but so do CDNs (even with ocsp/crl since hundreds of sites use a single cert. Domain fronting is getting more common too
"Your ISP is literally selling this information right now in the US"
Your ISP will literally still be able to sell this information after DoH is rolled out. Because they can see what IPs you're connecting to and in most cases hostnames can be trivially and automatically determined knowing only the IP.
Unless we centralise HTTP through a handful of gateways like we're doing with DNS (hello Cloudflare). At which point, why even bother calling it the web anymore.
Very limited with TLS. With webhosts, the PTR record means little. CDNs also obfuscate your destination. Shared hosting sites only care about the host field in the encrypted HTTP as well. Especially given the oversaturation of IPv4.
Keep in mind, it's not just what you visit but how often as well and a lot other details (dns is cached)
Yes, lets do some threat modeling. In the first model we have the ISP that host a DNS resolver. The traffic goes from the client to the server hosted by the ISP.
In the second model we have a CDN that host a DNS resolver. Where is the CDN hosted? At the ISP. The traffic goes from the client to the server hosted by the ISP.
How has the threat model changed? The CDN has a contract between it and the ISP, and legally this should mean that the ISP have no legal right to look in the server that they host and copy the information.
For law enforcement this should change nothing. I don't expect the CDN contract with the ISP to radically limit the secret police, nor the regular police, or even the courts ability to demand censoring of websites. The last part might however generate some court cases and thus delays before things return to the same situation we have today.
> Yes, lets do some threat modeling. In the first model we have the ISP that host a DNS resolver. The traffic goes from the client to the server hosted by the ISP.
> In the second model we have a CDN that host a DNS resolver. Where is the CDN hosted? At the ISP. The traffic goes from the client to the server hosted by the ISP.
hosts : files,dns
Damn it. When the bloody browser bypasses the OS then it is really a big problem.
> Your ISP is literally selling this information right now in the US. What are you even talking about?
Every time Firefox starts up it probably phones home to check for updates. The incoming request is traceable from the user's IP and Mozilla could figure out if the user is with a privacy-violating ISP: they could then only enable OS-bypassing DoH for those users.
Those who run Firefox in corporate networks would be unaffected, as would those who are were 'good' ISPs.
Also, as someone in Canada, I downloaded the "English" version of Firefox, which probably meant "en_US" locale: guess what, I'm affected. As are plenty of less technical people who don't understand about going into about:config and changing things to "en_CA".
> Also, as someone in Canada, I downloaded the "English" version of Firefox, which probably meant "en_US" locale: guess what, I'm affected. As are plenty of less technical people who don't understand about going into about:config and changing things to "en_CA".
The en-ca locale was only added to Firefox in September 2018, I think it's the default for any new downloads since then, but FF won't automatically change the locale for existing installs.
Sure, my point was just tangential to clarify on the availability of the en-ca locale for Firefox. I don't even know that DoH is based on the installed browser's locale in the first place. (I'd guess that it isn't, as I'd expect many non-US users use the en-us locale.)
Only for plaintext http. For ssl/https - the hostname/ip can leak with SNI, but should be safe with ESNI (encrypted SNI). The URL should be in the request, which comes after the TLS handshake (hence SNI, so that the server can pick a certificate before knowing the HTTP HOST header).
SNI is a problem - but not much worse than the fact that a mitm can see who talks to who (IP) - IMNHO.
Quite. I didn't mean to imply a host/ip header wouldn't leak today - but I see how my comment can be read that way.
In fact, siblings point about cf (cloud flare) is relevant - as cf eats the world, SNI will potentially be more of a problem; if you connect to site A via IP a, and B via ip b - not much is revealed if host headers A and B leaks, given that traffic to a and b is already obvious. But when you connect to cf on a "nearby" IP c, it suddenly becomes more of a problem that host headers for A, B, D and E are leaking. Not necessarily worse than when your ISP could see you talking to IP a and b - but worse in the sense that you reveal some information to your ISP that would otherwise only be known to cf.
Cloudflare states the same thing. In fact, Cloudflare provides much more detail than Comcast/Xfinity [0]. And, personally, I actually believe Cloudflare.
If I have to choose between the two companies it's a no brainer. This is Cloudflare's business, and their business relies on them upholding their privacy promise. Comcast/Xfinity has, in the past, engaged in DNS hijacking [1]. Comcast has had the worst ACSI score over all other businesses in the US more than once and consistently ranks very low [2]. Comcast won the worst company in America in 2014 by the Consumerist [3]. Comcast has intentionally deceived it's customers as we understand due to lawsuits [4].
I'm not sure what sort of jaded world we live in if one can say Comcast/Xfinity is a "safe harbor amidst the rest" with mountains of public information stating the complete opposite.
Cloudflare's business lost them over $100 million last year alone. The way they operate right now is not a viable business, and we have no idea what they will change when they need to become one.
Maybe you're new to the tech/security space, but the majority of companies operate at a loss as they grow and pivot their business. If you follow Cloudflare they've only recently begun to start to sell into the enterprise space with new products as in the SASE space and beyond their traditional DDoS/WAF/encryption plays. Even with those "legacy" products - Cloudflare never heavily sold into large enterprise compared to more notable names in the hardware security space that they now are beginning to compete with. Their business is evolving to include field sales that are aligned to selling in this manner, which is relatively new for Cloudflare (comparatively).
But just stating that Cloudflare is operating in the red currently isn't a justification for anything as it doesn't mean anything positive or negative without understanding their operational business model and targets.
I'm guessing your statement is making a leap by assuming that because Cloudflare is operating at a loss currently that they're going to sell your data against what they publicly state in their privacy policy? For a growth company - that would be one of the dumbest things for them to do. Because if they are caught in that lie they will sink themselves.
No, it clearly says that if they haven't figured out a business model yet, the business model they will end up figuring out might just as well be selling your data, so it's maybe not wise to make the internet depend on them not doing so.
The Internet is not dependent on Cloudflare now, or in the future. While FireFox has made a choice (a polarized one), the end user still has the freedom to completely disable DoH and CloudFlare - or choose whatever other service they'd like to use.
Mozilla has an agreement with Cloudflare. Again, it is in Cloudflare's best interest to not break that agreement. If they do, then we can all have that conversation. But just because they could break the agreement does not mean we should jump to any conclusion that they are currently.
It's odd to me that there are a lot of defenders of the status quo that is DNS. Something that is easy to manipulate, easy to profile and scrape passively on the wire (no need to even ask if nobody knows you're doing it), and is generally (with regard to security models) less secure than DoH.
Could Cloudflare nefariously start NXDOMAINing everything? Sure. So could your current ISP (it's likely they already are or already have). Cloudflare hasn't done that. While I have some reservations on the 3 letter agency involvement, that is my only unfounded reservation at this point. Until someone exposes, factually, that Cloudflare has considered selling users data, is selling users data, is planning on monetizing data collected around DNS, etc. I, personally, feel that Cloudflare is offering up a good service. They do allow APNIC to see DNS query data, but not source IP info (go read their privacy policy I linked in this thread).
The Internet has inherent underpinnings of trust. You have to trust your ISP to not MitM your traffic. You have to trust someone to resolve your DNS without manipulation. You have to trust websites to not sell your data back to Facebook, Google, Microsoft, etc. It seems as though DNS data hand waving with regard to Cloudflare is only a fraction of what we should really be concerned about. Do you really want your DNS traffic to continue to be unencrypted? DNS has always been centrally controlled. We have the ease with which we can distribute our DNS queries across multiple providers to not give insight to everything we do all the time. But at the end of the day we have to ask someone where Google is. DNS is the problem, not DoH - at least in my opinion.
You have to trust someone. Cloudflare has done a good job of being a good steward as I see it so far. I'm not saying anyone should trust them blindly or forever by default. But - who do you trust? Who is so free from monetary gain that they should be the single source of truth for all of your DNS queries? Who? I don't see anyone on the playing field that isn't selling something. They're either selling you access to the Internet, or they're selling ads, or they're building up a social graph of you by giving you access to free services.
The Internet is built on trust and that give and take.
Generally arguments are based on facts. You've provided none. Feel free to show me any facts that support your hypothesis. Technically, I know they're valid. However, debates and arguments are only productive with factual data. Because without it it's all subjective in nature.
> Oh, and straw-maning, too? Brilliant!
I'm not refuting something you didn't bring up. Your argument is akin to the following: you should stop using all computing equipment because the NSA could have compromised all of your devices before you purchased them, all networks you connect to might be selling your user data and MitM your traffic with valid root certificates, and all of the services you use are probably collecting and selling all of your user data to the top bidder. This, all, in direct contradiction to their published terms of service and privacy statements with no known deviations or factual allegations against.
Again, what your saying could be true. Do you have proof or facts that back it up? Can you show beyond a reasonable doubt that what your implying even might be true? And are you choosing to attack Cloudflare only in this regard while hypocritically leveraging other services without the same scrutiny? And I get that we need to start somewhere, but in my personal opinion, DoH improves the attack surface for the majority of end users. I do wish Mozilla would have a very big explanation in the browser that this changed and an easy button that was added allowing people to turn it on if they think that what DoH and Cloudflare offers is worthwhile. So there's that.
How is that relevant to your assertion that it is up to you to decide when something needs to be discussed and apparently trying to use that as an argument?
> I'm not refuting something you didn't bring up.
Could you please point to where I said we should conclude that they are currently breaking their agreement, then?
That's a blog post, not a privacy policy. Not to mention the phrasing still allows for them to do this, as long as the information isn't personally identifiable.
I trust Cloudflare and Google (the other major DoH proponent) not to sell my data, because they have no need to do so. They are subject to law enforcement inquiries just like everyone else, so this does nothing for privacy in that regard (and actually increases the attack surface).
This also does not separate who can see your DNS from who can see your traffic, in fact it consolidates it, and this is why both Google (who controls the browser) and Cloudflare (who serves a large portion of the internet) are proponents of it. It allows them to aggregate DNS information alongside request information in a way they could not previously.
I am aware that they both have policies in place which purport to prevent this behavior. It would certainly not be the first time Google violates their stated policies in the mission of serving advertisements, or the first time Cloudflare aggressively consolidates internet infrastructure to the detriment of the open web.
> I trust Cloudflare and __Google__ (the other major DoH proponent) not to sell my data, because they have no need to do so.
Isn't Google's entire business model... data collection? Maybe Google won't sell the data, but they'll use it and sell the information they gather with it (i.e. ad targeting). I'm not sure this is meaningfully better than selling data (though there are definitely arguments to be made there).
AFAIK CF isn't in the business of ads and really data collection is just a waste of their disk space.
It's also yet an other instance of the web browser taking over something that (IMO) ought to belong to the OS. Now with DoH if I have DNS issues I have to figure out if it's related to the browser's DNS or the system DNS. I can't use command line tools like dig or ping to troubleshoot the issue because it's not what the browser is doing. If DoH is so great I want to enable it for all my applications, not just my web browser.
People, let's just rip off the bandaid and make Chrome and Firefox bootable already, who needs the kernel overhead when the browser is going to reimplement the entire stack itself anyway. Also let's just make TCP only work on ports 80 and 443 because clearly the rest doesn't really serve any purpose anymore.
You can definitely do DNS over HTTPS/TLS for everything if you run your own DNS server, either locally or somewhere on your network. I do this, and it works great, both methods have their own advantages and disadvantages of course.
> We continue to explore enabling DoH in other regions, and are working to add more providers as trusted resolvers to our program. DoH is just one of the many privacy protections you can expect to see from us in 2020.
Cloudflare is just one of the initial providers and they indicate that they are adding more. Also, I'm assuming you can add your own custom provider based on the screenshot in the article. You can just disable the feature as well.
I trust my own DNS provider much more than I trust Cloudflare to be honest. Also, most DNS requests over that “insecure protocol” happened over a single network hop or two and never left the infrastructure of the ISP.
Cloudflare is now a public company and they need to aggressively monetize their services. Selling browsing data is a lucrative business and becoming “the” DNS provider for most users (while locking out all other players) is a great way to build a data monopoly.
Not to mention that being the number one DNS provider will give them many opportunities to break domain resolution for users that don’t use their DoH service, as they also control the DNS entries for many sites (they could e.g. make propagation via normal DNS slower or start providing only a limited set of entries over “insecure” DNS).
American ISPs can and do sell your data legally. I don't really trust my ISP (I run my own DNS server at home and tunnel its requests over to a cloud VM), but I trust Cloudflare even less.
I trust my ISP but not American companies. They roll out only in America but obviously it's coming, and they use locale to detect it? My locale is set to en_US too, surely I'm not alone doing it because of translated software. Firefox has a small market in America anyway and America is not the world. We know big tech is in bed with your three letter agencies.
"Legally" is dubious. Intercepting any private wire communication is a clear violation of federal law (e.g. 18 U.S. Code § 2511), and a violation of the law in many states (e.g. CA PC 631).
Unfortunately, the US government is one of the larger users of ISP surveillance activities, benefiting through the purchase of private data as well as using administrative subpoena to obtain the data collected by ISPs without due process or meaningful oversight.
This creates a conflict of interest which I believe is preventing the US from zealously enforcing existing criminal law which would be otherwise sufficient to significantly reduce surveillance by communications providers.
I dont use my ISP as my DNS provider, I have a custom setup using PiHole and other methods to provide secure DNS Resolution
Firefox should not be forcing this shit on me, time to search for yet another browser that will respect users. Mozilla is clearly more interested in commercial viability via their partnerships with large corporations (like CloudFlare) then in protecting Users
The only way to solve the ISP DNS inspection problem is by one of:
* Using DoH. For this to work with PiHole, you need to have a DoH resolver on the device, and then instruct the PiHole to recurse to that resolver instead - possibly your own in a VM somewhere?
* Using a permanent encrypted VPN to your own machine in the cloud and routing all DNS through that, then recursing to some DNS that you trust.
* Write your own encrypted protocol that communicates with some machine in the cloud.
Anything else and your ISP/evil-state-actor is able to to see your DNS traffic in plain-text. PiHole and DoH approach the problem at different OSI layers, you ideally need both.
The fact that it can be trivially blocked by anyone on the network path does not make it "much better".
Of course anyone on the "network path" can block almost any protocol; DoT isn’t unique in that regard.
The concern is many large businesses block port 853 but that's because prior to the development of DoT, there was no reason for IT departments to configure firewalls to enable it. Most organizations only have a handful of ports available, including 443, which is what HTTPS uses and therefore DoH works as a result.
I've been running DNS over TLS using the Unbound [1] resolver for my home LAN on a spare laptop for a few weeks now and it’s been great.
Given the privacy trade-offs between privacy and security, many IT departments would opt to make port 853 available for DoT rather than increasing the ability for their users to be tracked.
As I mentioned elsewhere in this thread, the article Centralised DoH is bad for Privacy, in 2019 and beyond [2] clearly describes the issues with DoH:
DNS over HTTPS opens up DNS to all the tracking possibilities present in HTTPS and TLS. As it stands, DNS over UDP almost always gets some free privacy by mixing all devices on a network together – an outside snooper sees a stream of queries coming from a household, a coffeeshop or even an entire office building, with no way to tie a query to any specific device or user. Such mixing of queries provides an imperfect but useful modicum of privacy.
DNS over HTTPS however neatly separates out each device (and even each individual application on that device) to a separate query stream. This alone is worrying, as we now have individual users’ queries, but the TLS that underlies HTTPS also typically uses TLS Resumption which offers even further tracking capabilities.
DoT only solves the SNI problem during the DNS request itself. It doesn't do a thing about the SNI during the request to the actual website, which is where all the privacy concerns are.
DoT only solves the SNI problem during the DNS request itself. It doesn't do a thing about the SNI during the request to the actual website, which is where all the privacy concerns are.
Sure, but until we have encrypted SNI, which is in draft, meta data is going to leak, but that's a separate issue from either DoT or DoH.
But because DoT doesn't use HTTPS, you don't get some of its downsides like using cookies for tracking, for example.
DoH shares the benefits and downsides of HTTPS. It sends out more trackable data than regular DNS, simply because HTTP supports things like headers and cookies. TLS session resumption functions as another tracking mechanism.
There’s a draft RFC [2] to address these and other privacy issues that weren't specified in the original RFC for DoH.
Is there an indication they are moving in that direction already? (Genuine non-sarcastic question)
They've built up a considerable amount of good-will in developer communities. Is there some historical indicator with cloudfare that suggests they are going to blow it all on their path to monetization, or are we extrapolating from other VC backed companies (which may be an understandable position to take, but why?)
Yes I think they will. Their positioning in the VPN, DNS, CDN and (soon) enterprise networking space will give them enormous visibility into a large fraction of what is happening on the Internet, and I simply cannot believe that a profit-oriented company will turn away from such a market opportunity.
Cloudflare isn’t really known as a privacy champion, they always put more emphasis on security, speed and reliability.
From a privacy perspective it’s pretty horrible what they do as well, because they decrypt and inspect all traffic between their customers and those customers users. Security-wise it might be great, but don’t confuse security with privacy.
I really hope that I’m wrong but I’m skeptical that Cloudflare will turn down such a big opportunity, and this move with DoH really seems to confirm this.
Mozilla has previously noted that Cloudfare is contractually obligated to keep the traffic private and not monetize or share it. That's not perfect, but without a law requiring it that's about the best you can get in the U.S. (assuming the contract has teeth in the penalties it imposes).
I'd be willing to accept a lien on the homes of the senior cloudflare and mozilla executives with a contract that will forfeit the value of their homes and allow me to sell them and donate the funds to charity, should it be demonstrated that Firefox-Cloudflare DoH is being used to surveil users.
There are many things that could be done. The problem is that the promises they make sound grand but aren't real, they wouldn't put the value of their homes at risk (nor would I encourage them to, I'd encourage them to not put themselves in a position where they could be forced to compromise the privacy of the public like this) ---- yet some user's lives can be put at risk by privacy-failures of their service.
That is pointless, Contracts are only valid if they have teeth, and I highly doubt CloudFlare agreed to any contract that exposes them to huge financial liability
So the question is "What happens when CloudFlare violates the contract" do they get a strongly worded email from Mozilla?
bad PR?
Or is it s bankruptcy causing event for the company. Anything besides that means the contract is worthless
In my world, everyone has a story about how an obscure but interesting to surveil service that they were involved with was DDOS attacked and immediately cloudflare sales was showing up offering to mitigate the attack for free by MITMing their traffic. ... Even showing up on the IRC channels of open source projects. I've personally witnessed it three times.
Even if it weren't for the fact that it would be gross incompetence if the NSA hadn't compromised cloudflare up, down, and sidewise since it's such an attractive target, the surveillance based sales-leads approach used by cloudflare has convinced a lot of people that they're engaging in a protection racket. Not just technies, either-- I've heard from executives who pay for cloudflare service that they think is a protection racket but they pay anyways because it's just a cost of doing business.
[I don't personally think it is, but I think that cloudflare is unethically creating a situation where some customers will believe this and pay as a result.]
It's such a lovely setup for a state attacker. Step 1. Compromise cloudflare (either by getting insiders into it, or by hacking them). Step 2. DDOS attack the thing you really want to monitor. Step 3. Cloudflare sales shows up and helps onboard the victim onto your borrowed surveillance platform.
People think that kind of stuff about AV companies, but at least AV companies aren't showing up within minutes of an attack saying "Gee, isn't it so terrible that you've got a virus. We've got a cure for that!". At least AV companies mostly don't send your data all back to their servers where god knows what happens to it.
Even where the problem is usually just a volumetric DDOS, the cloudflare standard solution is a full encryption unwrapping layer-7 MITM.
DoH without cloudflare would also gather complaint but the fact that the default centralized panoptiresolver is cloudflare contributes a lot to many people's discomfort.
So, I don't think cloudflare has amassed much goodwill at all, and that's even before getting into how their 'protection' made much of the internet unusable behind tor or other anonymization proxies.
> So, I don't think cloudflare has amassed much goodwill at all, and that's even before getting into how their 'protection' made much of the internet unusable behind tor or other anonymization proxies.
Funnily enough Cloudflare supports DNS over Tor[1][2], and I think they are the only one. Please let me know if there are others!
This is the most convoluted conspiracy theory I've read so far this decade.
You profess not to believe these theories, or at least not the first one. So why then repeat? It's just more untruths poisoning this debate, like any other going on these days.
And how does Cloudflare get the blame in your telling of this story, when it's your unnamed sources "you've heard" believing paranoid stories? DDOS were a thing before Cloudflare, and the incident numbers haven't much changed. So if it's Cloudflare doing it all now, they must have simultaneously convinced everyone else to stop.
The idea that their salespeople showing up when you're under attack is similarly strange: While I might agree that it feels somewhat creepy, is there any doubt that these things are easy to notice with some saved twitter searches and a google alert? It also strikes me as a potentially quite useful sales tactic. And yet, even though it's feasible and effective, they are supposed to forgo that channel to stop others from engaging in obviously flawed reasoning?
> This is the most convoluted conspiracy theory I've read so far this decade.
You must not get out much. :)
> things are easy to notice with some saved twitter searches and a google alert?
They are not doing this through twitter searches or google alerts. They show up when there is absolutely no mention of it anywhere, even sometimes when the attack is largely ineffective. Expectations like yours-- that they could only discover them from public sources-- probably contributes to people believing the attacks originate from cloudflare.
They use sampled netflow data from ISP to detect large scale DDOS attacks (presumably buying the information from arbor networks or similar, where they don't have their own coverage).
My domestic IPS is owned by a public company and I'm sure they need to aggressively monetize their services too. My point was just that you ultimately have to trust someone. Not trusting CloudFlare is a perfectly legitimate position to take.
>Formerly your browser still "phoned home" to your default DNS provider, using an insecure protocol.
This is kinda painful to read, to the point where I'm not sure if it's intentionally misleading;
DHCP will give you a DNS config, that DNS server can be local, remote, it can support DNSSEC or DNS over TLS (yes, that's a thing[0]). I even have configurations where a local DNS resolver on my machine (DNSMasq/unbound) would query _different_ recursive resolvers based on the domain I'm requesting.
DoH takes away huge amounts of configuration, and the ability to locally host DNS and ensures that a central body gets your DNS requests. The only "opt-out" in the current system is not using DNS at all, which is still an option. (NETBIOS/mDNS/Hosts)
Maybe a nitpick but i doubt dhcp is going to hive you a local dns server
> it can support DNSSEC
Which is irrelevent to the original complaint about "phoning home". DNSSec provides security against certain types of attacks like poisioning. Privacy & evesdropping are outside of its threat model
> DNS over TLS (yes, that's a thing[0]).
A thing with very little client support. Is it even possible to specify this via dhcp?
> DoH takes away huge amounts of configuration, and the ability to locally host DNS and ensures that a central body gets your DNS requests.
If you're doing this level of configuration, just disable DoH. Or host your own DoH server.
> Maybe a nitpick but i doubt dhcp is going to hive you a local dns server
Nearly every consumer-grade router on the market hands out IP configurations where said router is configured as a DNS server (the router then usually is configured to forward requests to the DNS provider of your choice, which is usually the ISP's DNS servers, depending on the technical ability of the person that set the router up). This is useful for things like accessing devices on your local network that have a GUI accessible via a web browser by hostname rather than IP address or, in the case of Netgear, intercepting requests to routerlogin.net and redirecting them to the router's configuration page instead of some page on the Internet.
If FireFox starts to ignore the OS-level DNS configuration, then these things are going to break and consumers who don't follow these things closely aren't going to know why or how to fix it.
> Maybe a nitpick but i doubt dhcp is going to hive you a local dns server
0_o Weird doubt,-- thats why DHCP can give you a DNS server. Otherwise, DNS discovery might as well work by just defining some /32s that always get routed to a nearby DNS server. :)
My DHCP servers at home give me a local DNS server... any corporate network that also has internal private naming will necessarily be handing out a resolver internal to that network.
I guess i was interpreting local in the sense of localhost. Which, fair enough, in context that is a silly way to interpret local as local network makes much more sense in context.
Give me a non-profit infra provider than I can donate to, similar to Let's Encrypt. Let's call it "Let's Resolve", give it a non-profit charter and org style, with transparency, governance, and strong privacy protections. Mozilla could even be one of the sponsors of such an org, thereby ensuring the values it supports are adhered to.
Open Street Map runs on a budget of ~$100k a year. The costs for such an org would be similar; DNS->DoH VMs, orchestration, labor, admin. I've warmed to Cloudflare, but you know how things usually go with for profit benevolence. The love always runs out. Always. And that's okay! Nothing lasts forever, but we need to start putting effort into orgs that are designed to last while protecting user citizens. Build trust, not companies.
Quad9 (https://www.quad9.net/) exists and is a 501(c)(3) DNS provider with a relatively reasonable privacy policy. It supports direct DNS resolving and has DOH servers available.
The problem is not so much the lack of available infrastructure but the lack of awareness of alternatives existing, so everyone ends up just using the known defaults (google or cloudflare mostly)
I'm dubious. If someone asked me to run such a thing and offered to pay for it, I'd turn them down:
It's too easy to be compromised (via hackers, including the state funded kind) or ordered (e.g. via an administrative subpoena, NSL, or plain court order) and fail to deliver on the expected privacy. This false sense of security might even get people killed, when they think their activities are private when they really aren't.
You might get a strong selection effect for parties who are less principled, thoughtful, knowledgeable, or even outright less honest. Why should someone trust them more than cloudflare (who is already seeing a substantial portion of user traffic, because if you don't use them-- you get DDOS attacks and then mysteriously cloudflare sales contacting you).
The situation with Let's Encrypt is different-- the SSL CA process is already fairly insecure and bogus certs are already easily issued to any party that can MITM traffic to the target server. Even ignoring that ... Any one rogue CA which is trusted by browsers is enough. So there is little to no incentive to compromise Let's Encrypt.
If someone asked me to run such a thing and offered to pay for it, I would do so in a heartbeat (build, staff, and move on). You don't get progress without pragmatism and compromise. The benefits far outweigh the potential downside. You want people who care leading the charge.
We should endeavor to build something good enough today, so someone in the future can build something better on our shoulders.
Parent post already covered this in the original comment: the ISP can already see all IPs and often SNI. Basically they still see the host names. DoH is just adding an extra party to that chain.
I’m not taking sides here but the argument was made, and valid.
Even if you run your own DNS server, it's still making queries to other DNS servers. With regular DNS, this is not encrypted, of course. Almost nobody uses DNSSEC. So there's a lot of "trust" going on.
Firefox choosing reasonable defaults that improve security for regular users in practise given the state of the world at this time, seems reasonable to me.
By a similar token, you can opt-out of web pki by specifying all your own root CA's. But i hardly fault firefox for including sensible defaults.
99 % of users won’t touch default values, so it’s not a valid excuse.
I really have come to the conclusion that privacy is just a marketing feature for Mozilla. They e.g. also do nothing against data exfiltration by popular extensions although they have known that issue for years.
If they’re really serious about privacy they should have waited to implement DoH as an open standard and allow more DNS providers to support it. The browser could then simply see if your default DNS supports it and if yes switch to DoH.
This really smells like some kind of data deal between them and Cloudflare. This is not surprising because DNS data is really valuable and passive DNS monitoring is used for many purposes, e.g. security and marketing. Controlling this data gives you many interesting business opportunities, hence I can understand why Cloudflare and Google are after it.
It’s also revealing that they don’t enable this in the EU, because they rightfully fear that it’s not compliant.
> They e.g. also do nothing against data exfiltration by popular extensions although they have known that issue for years.
This kind of sentiment compels mozilla into becoming an apple-like gatekeeper to a walled garden because people conflate the trustworthiness of extension authors with mozilla's trustworthiness, which leads to less software freedom, a single point of failure and a less diverse ecosystem.
There simply should not be an API that allows exfiltrating the URL history of a user and then send it to a remote backend, at least not without making this very, very explicit to the user (which they currently do not).
You don't need to be a "gatekeeper to a walled garden", it's just necessary to have sensible APIs that respect users privacy. I think a browser that puts privacy as its primary feature should be able to do that.
This has nothing to do with an API. Any kind of extension that acts automatically (i.e. doesn't exclusively spring to life when clicking on an extension-specific button) will have to inspect the currently open tabs, page contents or network requests to decide whether it has to do its thing, which means it has access to this kind of information anyway and could exfiltrate it through standard web APIs (fetch/XHR).
This is not on mozilla, their current extension API surface already is much more limited than the old one (killing off some preexisting usecases in the process) and still has many ways to get this information.
It's kind of asking that git shouldn't have filesystem or network access.
Well, I was part of a team that proved that one of the most popular Firefox extensions (Web of Trust) stole and monetized user data, archiving every single URL a user opened and selling it to anyone who was willing to pay (the journalists I worked with even got a free sample containing the data of 3 million people). The extension was then banned for a few weeks before being reinstated, and happily continues to exfiltrate data from millions of users today. So pardon me if I have a slightly different view on this.
It is simply not true that building systems with privacy in mind is not possible. I can think of several ways to drastically improve the privacy of web extensions by providing audit logging or more fine-grained control over permissions.
Comparing end-user software like Firefox with developer tools like Git is also misleading, I find. There are countless studies that show most non-expert users don't know what is happening with their data and are not able to judge the risks they're taking when installing software like browser extensions.
Again, it's perfectly fine to build a product and not care much about user privacy, but if your main selling point is privacy this is different. It's just pointless to have the most advanced content blocking mechanisms when you allow browser extensions to circumvent them all.
> I can think of several ways to drastically improve the privacy of web extensions by providing audit logging or more fine-grained control over permissions.
You were talking about API surface though. Neither of these things are API surface in itself. They are after the fact, informing the user what it can do and what it did with those APIs.
> It's just pointless to have the most advanced content blocking mechanisms when you allow browser extensions to circumvent them all.
I don't think so. It's not pointless. It just means you need to trust more than mozilla, you ALSO need to trust the extensions, just like you need to trust many other things in your system. The error here is assuming that everything should be reducible or can be reduced to a single source of trust.
> There are countless studies that show most non-expert users don't know what is happening with their data and are not able to judge the risks they're taking when installing software like browser extensions.
Perhaps. But if you follow that argument then you end up with a locked-down system with little flexibility, which I was referring to as apple-style walled garden. Some people may value such a thing, but I wouldn't use or recommend firefox if it became something like that. I would flee in terror.
Reducing the API surface is also a way to improve privacy, and I also see many ways in which you could do this, e.g. by not revealing the path (or at least the query part) of the URL to extensions. It's entirely doable and most extensions can work fine without knowing every single URL you open. Apple, Google & FB have all shown that this approach works to improve privacy (not that I want to endorse them here as privacy champions), so why should that not work in the browser?
You can also have an officially sanctioned distribution channel like an app store and still retain the ability to install any software you want. The problem as I see it is that Mozilla provides a free distribution and marketing platform for malicious actors via their extension store, and I think this is in violation of their principles (especially principle 4) because it nullifies most of the security features that their browser offers. It's like putting up a 10-feet reinforced concrete wall to protect your house from intruders and then leaving the backdoor wide open.
I really don't want to argue about this here, I just find they're not doing the right thing and I find it sad, because I care a lot about privacy and I think recently Mozilla just took some bad decisions regarding that.
> It's entirely doable and most extensions can work fine without knowing every single URL you open.
It's needed by: Greasemonkey (to determine whether to run a script), content blockers, password managers (to determine whether to fill in on that site) and any extension running web-standards compliant javascript against a page's DOM (i.e. any page-modifying extensions) as inherent part of standards-compliance
> You can also have an officially sanctioned distribution channel like an app store and still retain the ability to install any software you want.
In theory, yes. But in reality mozilla has been making it more and more difficult to install extensions. You cannot install extensions not signed by mozilla on stable firefox. They already have assumed exclusive control there.
No, it would be straightforward if they asked the user something like this:
"Is it ok that this extension sends every single URL you open to an untrusted third party for processing? Please note that URLs might contain sensitive data like access tokens or session information."
Even so, I don't think such an API should exist. And if you absolutely need to have something like this you should restrict it to domain information by default, cutting away the path.
I can understand that Google might not care much about this (Chrome itself is a data collection platform), but I really don't get why Mozilla is so lenient about it as well, as their main differentiator has been user privacy for years.
> Even so, I don't even think such an API should exist.
There is no "exfiltrate all my history" in the webextension APIs. What exists are two distinct and reasonable components.
A) accessing browsing history/current tabs/network requests¹. all things required for extensions to work
B) ability to make generic network requets
Combining these two can be used to exfiltrate data. But that does not mean that any particular extension that has access to both will also exfiltrate private data. Thus a blanket warning would be overly broad and anything more targeted would require manual sourcecode inspection.
¹ Those require separate permissions, but for the purpose of the discussion they can all be used to harvest data
Wasn't there a big story on HN about how chrome had disabled the ability for plugins to see your URLs and how adblocker plugin makers where up in arms about it?
DoH is an open standard. DoH is also better for the 99% of users who don’t care about DNS resolvers and use their standard, shoddy and privacy invasive ISP provided one.
Just because something is open doesn't mean that it's ok to push it on users at will. DoH is highly controversial and not a standard, there are only a handful of players that push it for their own benefit.
Also, in most parts of the world people trust their local ISPs more than giant US corporations, you should not assume that everyone welcomes this centralization.
> in most parts of the world people trust their local ISPs more than giant US corporations
On what is this assertion based on?
I'm part of this world and I'm not a US citizen. I do not trust my local ISP, because they log and report traffic to local security agencies. It's bening at this point, tracking illegal activities, but they can connect whatever I do with my real name and address.
If I were to guess, in most parts of this world people don't have freedom of speech and fear repercussions from their government for their online activity.
The profiling that US companies do for serving better ads is essentially a first world problem, and a pretty irrelevant one for most people.
Also if we had such deep mistrust in US companies, first of all we shouldn't be using devices and operating systems built by US companies.
My ISP has to obey the rules of my government, and it is not allowed to sell my data. It's in my country, with my regulatory bodies and close enough that I (or a group of people like me) can sue them, if they start doing bad things.
What the hell am I supposed to do again cloudflare?
> I really have come to the conclusion that privacy is just a marketing feature for Mozilla. They e.gg. also do nothing against data exfiltration by popular extensions although they have known that issue for years.
I thought about this recently, and the move to HTTPS-Everywhere is the biggest issue here. In the old days, you could have something like the @guard firewall on Windows, which could examine all outgoing HTTP connections, and block ads and malware by examining not just the hostname, but also the URI of each request. This meant it was separate from the browser, worked with all browsers, and didn't break every time your browser is updated. It's pretty easy to write a similar tool on UNIX to act as a proxy, too, and make it network-wide through your OSS router.
Nowdays, because it's all encrypted with certificate authorities and all, it's much more problematic to block ads and malware, because then you'd also have to intercept HTTPS, and manage certificate authorities and such. I guess it's still doable in principle, just more involved, with a considerably worse UI? Has anyone tried anything like that in the HTTPS world, do any solutions exist as FLOSS at all?
Intercepting HTTPS is possible, but not easy. It just requires configuring your browser to use a known key pair for client authentication so that you can MITM yourself from a local or network proxy.
On the consideration of trade-offs, I think HTTPS-Everywhere is completely worth it. It may be more complex to intercept your own traffic, but since you are in control of one of the endpoints and the ISPs (which in the US are openly trying to market your browsing data) are not, I still consider it an overall win for privacy.
HTTPS intercepting proxies ("middle boxes") are commonly deployed in the corporate world. Firefox-- and internet protocols themselves-- makes many concessions to avoid gratuitously breaking these things.
For free software, squid ssl-bump works, though is something of a pain to configure!
> makes many concessions to avoid gratuitously breaking these things.
Or to look at it from another perspective, if you do this then in configuring the browser to accept it (typically, adding a private CA as trusted) you agree that you broke the browser's provided security promises and are happy without them.
In principle this can be safe if the middlebox you use has its finger on the pulse (usually dubious) and you're applying security updates to the middlebox as you would a browser or other outward facing software. So far I've never seen one I'd trust.
> Cloudflare is just one of the initial providers and they indicate that they are adding more. Also, I'm assuming you can add your own custom provider based on the screenshot in the article. You can just disable the feature as well.
Or go for https://firejaildns.wordpress.com/ - Linux workstation DoH proxy, more than 60 DoH providers. When you start, the proxy chooses one at random. You can also set the servers in Firefox.
If you just want a DNSCrypt and DoH proxy for Windows you can use Simple DNSCrypt. It also has over 60 DNS providers included and has data on which ones use filters to block requests, which ones log requests, and which ones support DNSSEC. How much you trust this data is up to you.
Correct me if I'm wrong, but the concern I have about browser-controlled DoH is that it seems like it could make it harder for a tech-savvy user to assert control over their own network. IIRC, most network-level ad-blocking operates at the DNS level. I've also personally blocked telemetry by setting my router's DNS proxy to resolve certain telemetry servers to 0.0.0.0. It's my understanding that DoH would bypass that. Couple that with Google's planned neutering of Chrome's ad-blocking API, and it seems like it will become increasingly hard for end-users to avoid ads.
And the fact that DoH uses HTTP seems like it would make it impractical to block as a protocol.
I think I would have preferred an encrypted DNS protocol that ran on its own port, at least.
For existing configurations, it makes it a bit trickier to implement. If you ad the aforementioned rules to your DNS and/or IP block list, then Firefox will default back to using the system configured DNS.
But DoH is not targeting ad-blocking specifically, but rather intermediaries that are outside of the local network. There is evidence of ISPs injecting traffic (Comcast/Xfinity) or selling user traffic (AT&T) and this was designed to close one of the last gaps for a fully encrypted flow.
It's possible to setup a DoH server for your local network's DNS resolver, so that all of your traffic leaves your network encrypted, even if not encrypted on your local network.
Firefox tries to recognize some personalized DNS servers and prefer them to DoH in cases where it finds them. The FAQ here suggests that work is ongoing and they are hoping tech-savvy DNS alternatives used for things like parental controls and ad blocking meet them somewhere in the middle in terms of making it easier to Firefox to auto-disable DoH when a user has explicitly opted in to more power user configurations.
Similarly related is the general idea is that if you have the tech savvyness to setup a PiHole in the first place, you should be able to find the Firefox settings on your devices to disable DoH, and Firefox isn't hiding those settings, they are just trying to make a default that is better for more people (the folks that aren't tech savvy and have a different threat model than the power user with a PiHole or similar).
> you should be able to find the Firefox settings on your devices to disable DoH,
You should be able to find a buried config option to regain your privacy is _not_ a position that we should consider acceptable!
There are serious logistical challenges keeping the option off even at a household level.
At the moment it isn't difficult to block at the network level, but presumably they'll start evading those blocks eventually or otherwise the claim that this is intended to prevent monitoring by ISPs will seem pretty hollow.
Mozilla seems to have made it clear that where DoH is on by default the config option won't be "buried", particularly because out of the box multiple options will be provided (both Cloudflare and NextDNS). That you see it as "regain" says we probably have different threat models/assessments here, I'm not sure I can help you much further with the paranoia associated with your current threat model.
Paranoia? What exactly is paranoid about being concerned about the browser sending all firefox users traffic for an entire nation to a single party which has the technical ability to monitor all this traffic and under which current norms have essentially zero protection under the law?
Surveillance at large providers is an unambiguous fact, centralizing all user's traffic at one makes it tremendously easier.
The majority of US broadband users are on comcast, which as reported-- in spite of stinking in many respects has made similar public commitments to cloudflare to not monetize this data.
I think you likely have it reversed which threat model is more fringe and which is more concerning.
> At the moment it isn't difficult to block at the network level, but presumably they'll start evading those blocks eventually or otherwise the claim that this is intended to prevent monitoring by ISPs will seem pretty hollow.
Have you considered using a different browser? One that aligns more with your values?
If you use the nextdns DoH provider in Firefox you can actually configure your own adblocking domains even when you're moving around across networks. Just FYI
> If you use the nextdns DoH provider in Firefox you can actually configure your own adblocking domains even when you're moving around across networks.
Uh. Doesn't this prove that Firefox's DOH implementation is sending strong per-user identifying information to the server?
If you configure a personal NextDNS URL as the DoH provider then unsurprisingly NextDNS will know that URL was used, and personalise things accordingly.
If you use Firefox's defaults but pick NextDNS from the list, you don't get personalisation as NextDNS has no idea who you are.
A nice thing about DoH here: For DNS over TLS NextDNS has to hide the configuration ID in the hostname, which as a result is revealed in SNI, but for DoH they can put it in the path and so it is encrypted like everything else.
> ...for DoH they can put it in the path and so it is encrypted like everything else.
Wait: You mean to say URLs are encrypted? I thought not. There must be a reason why GET requests aren't used for secret-sharing, for instance, as opposed to POST. What am I missing?
The scheme will always be HTTPS and that isn't sent anywhere but it's implied.
The userinfo (often empty) is encrypted and delivered to the server. This could be login credentials but in the modern web it's largely unused.
The hostname someserver.example is delivered to the server unencrypted using SNI (Server Name Indication) before encryption switches on. This is used to enable virtual hosting - the server may behave differently depending on which name you want. The Encrypted SNI work (eSNI) at the TLS Working Group intends to standardise a way to encrypt this information - note that if your IP address only serves one single web site the hostname doesn't give much extra away so eSNI is mostly interested to bulk hosts, the cloud and so on.
The port 1234 is not delivered anywhere but it's implied since the connection will use this TCP port.
The path /foo/search is encrypted, this is the part NextDNS uses to distinguish one customer from another if you use their custom URLs rather than the built-in default in Firefox.
The query parameters ?term=goose are encrypted
The fragment identifier #egg is not sent to the server this is used only locally in the browser engine itself.
The reason you shouldn't design web sites to use GET for secrets is that URL ends up in the user's URL bar and gets bookmarked or shared with friends.
ESNI only helps if you're fronting through things like cloudflare, again putting more eggs and information into a single basket and making them a more valuable target for TLAs.
True, centralization is a downside. But the alternative is having no privacy from government agencies. Even if you somehow believe your ISP won't be subject to these hypothetical interception orders that CloudFlare would be subject to (why?), there are plenty of points to tap in between your ISP and the website you're visiting.
> mike@blob:~$ host 208.80.153.224 224.153.80.208.in-addr.arpa domain name pointer text-lb.codfw.wikimedia.org. mike@blob:~$ openssl s_client -connect 208.80.153.224:443 2>&1 | openssl x509 -text|grep Subject: Subject: C = US, ST = California, L = San Francisco, O = "Wikimedia Foundation, Inc.", CN = *.wikipedia.org Yeah, our ISPs are going to be totally in the dark thanks to DoH. /s
minjiexin.com resolves to the same IP. So, you see an HTTPS connection to 208.80.153.224, what's the user doing?
In this particular case, the ISPs db entry could simply be "customer visited either wikipedia.org or minjiexin.com", and that would be practically as good as before DoH.
Or the ISPs database could simply be of IP addresses connected to, and the purchaser of that database could apply identification based on which other IPs were connected to around a similar time.
If it's your argument that mapping IPs to "websites visited" is not 100% accurate, then of course you're correct... So what we need to do is figure out how accurate it is. Because if the answer to that question is 95%, then the whole value proposition of DoH flys out of the window. Why massively centralise DNS to just make a tiny dent in the problem?
If the answer to that question is 5% rather than 95%, then I guess that would mean we've centralised the web so far already behind gatekeepers like Cloudflare+Google+AWS+Microsoft, that it doesn't really matter if we go and centralise DNS for web usage in the same way, as the web is already fucked.
Come on, this is an overstatement. They have a non-public contract with mozilla. What happens if they break it and get caught? Probably the only consequence is that firefox stops using cloudflare ... eventually.
Look at what has happened with misbehaving CAs. The responses have ranged between nothing and removing them 5 years later.
> your ISP cannot see that you are visiting facebook because the IP shows up us cloudflare
Yes they can, it's visible directly in the https requests as SNI. (not to mention in the sizes of traffic that go through).
> now that is a "massive attack on user privacy"
How so? If anything it's just another example at how this DoH approach does not actively protect users from ISPs.
> The responses have ranged between nothing and removing them 5 years later.
Certainly you've got an example of "nothing" and of "removing them 5 years later" to start with, right?
DigiNotar is the most obvious example of a "misbehaving CA" that you might be concerned about. In June 2011 their services were broken into and they decided not to tell anybody. There were no technologies in place at that time which could detect problems like this without DigiNotar's assistance. At the end of August a google.com certificate issued this way was used to attack Iranian web users, but Google's Chrome browser had pinning protection (only for Google's own services) and so at this point it detected the attack in progress.
Mozilla shipped updated Firefox versions which distrusted DigiNotar's public root in about 48 hours (not "5 years") and over subsequent days distrusted the entire DigiNotar hierarchy including those parts the Dutch national government had insisted were fine (they were not fine).
The public reactions at the time mirror your incredulity by the way, people who grep'd their newly updated Firefox and discovered DigiNotar's CA certificate (in fact blacklisted explicitly) as "proof" of a conspiracy by Mozilla to send all their traffic to some scary foreign company.
Perhaps DigiNotar just isn't recent enough for you. So let's look at rather smaller deviations from the more recent past. In 2015 WoSign (a QiHoo 360 company which operated a CA) acquired the Israeli CA StartCom in secret. No significant countries have any mechanism in place to detect this (a potentially hostile acquisition of a private company) and so the browser vendors had no idea until mid-2016.
Not telling Mozilla about this was already a violation of both agreements (for WoSign and for StartCom). But in 2016 WoSign/ StartCom (now one shared controlling mind) minted new certificates using SHA-1 signatures for several outfits, notably an Australian financial services company named Tyro. Since new SHA-1 certificates were prohibited in browsers in 2016 these certificates were back-dated to appear they'd been issued in 2015, another violation of the rules. The Tyro cert was probably actually issued in June 2016.
After conducting an investigation which included having Israeli documents assessed by a Hebrew-speaking lawyer and a bunch of digital forensics work, by September of that year Mozilla was instituting partial distrust of WoSign and StartCom, and in 2017 the browser distrusted them entirely. Other vendors followed suit (very belatedly in the case of Microsoft).
Or one of a miriad of other ways to get a hint about the hostname of the service you're connecting to, at which point they can automatically do forward DNS lookups to confirm what matches.
DoH only adds to the number of organisations that can see your web traffic. It does not reduce it, or shift it to a more trustworthy organisation. It just adds more leaks.
DoH/ESNI don't stop your ISPs knowing exactly what sites you're visiting unless we centralise HTTP behind a handful of benevolant gateways the same way Mozilla is doing with DNS.
My ISP is legally bound to respect my privacy. I have regulatory bodies literally 10 minutes away, that can deal with tham, and a court system where I (and many more like me) can sue the ISP if they do something bad.
What can I, citizen of small EU country, with an en_US firefox, do against cloudflare?
It's a balance. Do you want your plaintext DNS request sent to starbucks or your local unsecured public wifi, or do you want it sent encrypted to your DoH server of choice?
That's fine for more technical users who are aware of how to mitigate this kind of issue, but then those same more technical users will also likely know how to disable DoH.
For the majority of users who may not understand the risks around plain text DNS, there are advantages to it being encrypted.
However, my comment was within the context of the parent's, which was talking about how this feature is beneficial to non-technical users; some of which may not be able to afford to pay for a VPN that (probably doesn't ...) MITM or log traffic.
Ideally this would be a standard component of home routers, especially some easy wireguard QR-code setup. But yes, until this happens it's something for more tech-savy users.
Not once DoH-in-the-browser becomes a default, percolates down to electron and then gets baked into a dozen mobile and desktop applications with little control or insight for the user or admin.
This has always been a poor argument. Especially for FF which is mainly used by Technical people
Chrome a d IE are used by people that do not understand the risks around DNS
I use FF because I am / was tried of IE and Chrome telling me how I should use thier software, now Mozilla is making the same moronic choices for me instead of empowering users
This is not an accurate statement, for the commonly accepted definition of "snake oil".
Your privacy concerns are, from an angle, legitimate (although encrypted protocols, as a general rule, are more private than plaintext protocols), but this is a bit over the top.
TFA also mentions that they are partnering with NextDNS, so your claims about centralization are on shaky ground, too. I personally use NextDNS on my whole LAN. They're great!
I think his point is about the default behavior pointing to Cloudflare. Unless the user changes the DNS provider setting, everyone will be on Cloudflare. With that said, I think this is pretty over-the-top. Part of the reason Cloudflare is the default (and NextDNS is an option) is because they are abiding by Mozilla's Trusted Recursive Resolver policy: https://wiki.mozilla.org/Security/DOH-resolver-policy
The only way Cloudflare itself can cause users a privacy issue through the use of its DNS service is by lying to them. They have already agreed not to sell or grant the data to any third party or use it for advertising, etc.
The other concern nullc has is that hackers will infiltrate Cloudflare because it will now contain data on all US Firefox users' DNS queries unless those users change default settings. OK. I guess. However, I will say that I trust Cloudflare a whole heckuva lot more than I trust Comcast, Charter, AT&T, Verizon, etc. to be practicing good security. There are also probably more people on the mega ISPs than there are Firefox users, and many DNS queries these days originate from platforms that aren't even PCs (such as home theater streaming sticks) which will still be pinging default DHCP-received DNS providers. If anything, I see this decentralizing DNS request data.
The mozilla policy allows cloudflare to permanently store and exploit per-domain-name but not per user data. So even going by the letter of the policy and considering cloudflare alone there is still a privacy loss.
Moreover, the current legal standard in the US is that users have no expectation of privacy for data that third parties have stored about their activity. As a result there is potentially limited to no due process protection for user information in this scheme. Cloudflare could be required to turn the information over via an administrative subpoena and without the oversight of even a court or any ability for the impacted users to learn about or challenge the surveillance.
> I will say that I trust Cloudflare a whole heckuva lot more than I trust Comcast, Charter, AT&T, Verizon, etc. to be practicing good security
Than any one of them? I could imagine that. Than all? Cloudflare is a much bigger target.
> I see this decentralizing DNS request data.
Could you elaborate on that? I see this as massively centralizing DNS request data (onto cloudflare) and this change is the most problematic part of the whole thing.
> Could you elaborate on that? I see this as massively centralizing DNS request data (onto cloudflare) and this change is the most problematic part of the whole thing.
1. Firefox's browser marketshare is around 10%. This moves roughly 10% of DNS requests off ISP DNS providers to Cloudflare. Each of the major ISPs controls more than 10% of the broadband market.
2. It's only impacting Firefox browsers. To get an overall picture of the DNS request landscape and privacy, one has to include every DNS request made by a computing device that doesn't go through a Firefox browser. Even for Firefox users, the vast majority of their DNS requests probably don't come from web browsing in Firefox.
3. Firefox also makes it very easy to switch DNS providers to DHCP default or NextDNS. Of course users can still use custom options as well. Many Firefox users are probably savvy enough to exercise these options.
Based on what I've laid out above, I would guess that this change by Firefox might be redirecting a low-single-digits percent (very possibly less than 1%) of DNS request traffic to Cloudflare vs. where it went previously. That sounds like decentralization to me.
My concern about DoH is that it gives marketers and other spies the ability to do DNS lookups while evading my defenses -- regardless of whether or not I'm allowing my browser or other software to use DoH.
The only solution to the problem that I could come up with was to install a MITM proxy in my LAN so that I can detect and filter any sneaky DNS lookups.
I'm still very peeved that Mozilla has forced me to take such measures.
Marketers using hardcoded private servers are the easiest thing to defend against: just block those servers. That fact is one of the big reasons why marketers and other spies don't do that -- they use DNS lookups to find the mother ship.
However, now marketers can use DoH, combined with public servers that would cause disruption to block, to be able to engage in lookups without a means of detecting or blocking them short of doing a MITM setup.
> do you actually do that on your network right now?
Yes, I installed it months ago to defend myself against DoH. I MITM all HTTPS connections, detect DoH lookups, and block them.
Safer protocols don't care who or what they protect. Even if browsers didn't use DoH, other devices could. And any protocol Mozilla can use to protect their users will also work for other devices.
I don't think it makes sense to bemoan the newfound existence of safer infrastructure for everyone just because devices you don't like can also use that infrastructure.
> Even if browsers didn't use DoH, other devices could.
Precisely so.
> I don't think it makes sense to bemoan the newfound existence of safer infrastructure for everyone just because devices you don't like can also use that infrastructure.
I'm not. First, I don't think this is actually a "safer infrastructure" compared with other DNS encryption schemes, because it opens a new hole.
Second, this isn't about "devices I don't like" using an infrastructure. This is about software and websites being able to bypass a layer of my defenses.
> First, I don't think this is actually a "safer infrastructure" compared with other DNS encryption schemes, because it opens a new hole.
Browsers are completely correct to treat the network as hostile in their default configurations, unless explicitly configured to trust something. More prevalent end-to-end encryption is a good thing. And DoH makes it easier to get encrypted DNS requests through without having them blocked by hostile networks who want to intercept those DNS requests.
If an encrypted DNS scheme is blockable by you, it's blockable by an ISP. There will not be an uproar about it, any more than there's currently an uproar about ISP's selling DNS-based browsing information about their users. It will simply fail.
> More prevalent end-to-end encryption is a good thing.
I agree -- I am not arguing against more prevalent e2e crypto at all.
> If an encrypted DNS scheme is blockable by you, it's blockable by an ISP.
Perhaps, but it's also possible (unless you're using DoH) to evade those blocks without a great deal of difficulty.
I'm not arguing with anything you've said here, really. I'm just pointing out that the way that DoH works means that there is a security hole that makes it very easy for marketers and other spies to evade your protections against them.
So yes, DoH brings some security gains. But at the same time, it also brings some security losses. Whether that tradeoff is good for you should be a decision you can make -- but again, due to the way DoH works, you no longer have that choice available to you without going to extreme measures like I have.
Why couldn't such a spy just hardcode their own DNS server IP address, rather than using your network provided DNS server? If the answer is that you'll blacklist the spy's DNS servers, then how is that any different than the situation with DoH?
DoH isn't adding any value for the spy unless you are doing deep packet inspection of any packet that contains DNS data.
> If the answer is that you'll blacklist the spy's DNS servers, then how is that any different than the situation with DoH?
There are two differences that DoH brings up about this.
The first is that because mainstream DNS providers are beginning to support DoH, there is no need for anyone to set up their own private DNS server. In fact, they wouldn't want to -- much better to use a real one that can't be blocked without causing unacceptable collateral damage.
The second is that DoH hides the entire interaction from me (unless I do what I did -- implement a MITM proxy to decrypt all HTTPS traffic).
> DoH isn't adding any value for the spy unless you are doing deep packet inspection of any packet that contains DNS data.
Sure it is. It effectively disables a layer of defenses from the spies.
FWIW, I've found that running a local unbound server with moderately aggressive caching makes a visible improvement in browsing speed. For us technical folks, it worth doing for the speed up even without getting into the configurability/privacy implications.
I have had the exact same experience. It's one of the first things I verify whenever I connect from a new location – are my queries being resolved by my local unbound or not.
Mozilla claims that Cloudflare is not paying them, and claims that they have a contract with cloudflare which prohibits them from selling the data.
I don't think that this improves the situation substantially. The history of internet privacy failures is full of empty and unrealized promises, and no amount of contracts or promises can trump a court order or a NSL. "Has no ability to collect" is the gold standard, and the only level of protection that guards against compromise and blanket state surveillance activities.
AFAIK they also have never published the contract itself, though doing so wouldn't address the above points.
Edit: After carefully reading the cloudflare privacy statement ( https://developers.cloudflare.com/1.1.1.1/commitment-to-priv... ) I believe it unambiguously states they will collect "aggregate data" such as how much traffic each specific domain is receiving and use it for their own 'development' purposes. To me this seems extraordinarily valuable by itself, quite a windfall.
ISPs can and do sell your information, and can also be served a warrant or NSL. Cloudflare, by contract, is prohibited from doing the former, which is a net improvement even if they're still subject to the latter.
It's an incremental improvement, but a positive one.
I would certainly love to see an even better protocol for Internet name resolution that prevents anyone from having name-lookup information, but in the meantime, DoH seems like a huge step forward in ensuring that no unencrypted traffic is visible to the ISP or local network.
Your ISP, however, is not prevented from collecting and selling your data by DoH. So the addition of default DoH in cloudflare adds an extra party that can intercept your traffic but does not remove any.
> DoH seems like a huge step forward in ensuring that no unencrypted traffic is visible to the ISP or local network
DNS traffic is a much richer and more valuable resource than a simple list of IP sessions.
Yes, of course your ISP can see who you're connecting to and sell that, but denying them (and anyone else) the ability to collect all DNS traffic is better than not denying that.
DoH is significantly richer than DNS itself because of session reuse.
DNS is cached, other than potential ambiguity related to shared hosts (which can be resolved by looking at SNI)-- I'm failing to see how DNS is richer than the traffic itself. Less costly to monitor? Sure.
Agreed. Unless that contract includes heavy penalties for selling and/or losing that data, its toothless nonsense. The fact that the contract hasn't been published is also problematic. If everything is above board, why hide?
>Mozilla claims that Cloudflare is not paying them, and claims that they have a contract with cloudflare which prohibits them from selling the data.
As you said, this does not improve the situation. Mozilla can't even verify it.
Also it could be a reverse data selling situation like with Google: They don't sell the data, companies pay money to Google to display ads to the users. Since they have so much data, they can target specific groups more easily. Data doesn't even need to leave Google for that to work.
This seems unnecessarily alarmist. DNS over HTTP doesn't protect against state-level legally-mandated surveillance because it's not designed to protect against state-level legally-mandated surveillance. There are no solutions to the problem you posit that don't involve SOME kind of trusted name authority somewhere that is, effectively by argumentative fiat (i.e. not really) "out of the reach" of whatever government it is that you don't trust. That's not something you're going to find a technical solution for.
The real problem addressed by DoH is the routine surveillance and hijacking of "presumptively public" names by local network operators. And it works comparatively well for that.
By "comparatively well" you mean defeated in bulk by deploying sampled netflow with a couple lines of router configuration-- which almost all major ISPs already have deployed for monitoring purposes.
> But there is no guarantee that these mitigations will continue to work.
This is the biggest problem. It used to be that Firefox was on your side, but now it's turning into the we-know-better-than-our-users Chrome, where they don't even feel like guaranteeing that disabling this malicious and unwarranted service today will continue to leave it disabled tomorrow.
> Newer TLS will eventually protect me from the former (in combination with DNS encryption).
False. Your ISP will see a port 443 connection to 151.101.121.140 and then lookup that IP in whichever of the numerous IP->Website DB's they're using and discover you visited Reddit.
DoH didn't hide from your ISP that you visited Reddit. It just added Cloudflare to the list of orgs that know about it.
Potential fix: Centralise HTTP behind a handful of shared IP addresses so the IP->Website mapping isn't so easy. Did somebody say Cloudflare?
I think this is generally a good thing. Two questions I've often seen surface on HN though weren't answered:
1. Isn't this better implemented at the OS level?
2. Isn't centralisation to two DoH providers more centralised than five large ISPs?
Others are probably better suited to answer, but the answers I can think of:
1. Yes, but it is not, so this solution is second-best. If Operating Systems decide to tackle this problem at some point in the future, Firefox can always be changed again to use that.
2. Given that Firefox doesn't own the full market, the net result is indeed less centralisation: five ISPs that handle traffic by other browsers, and two DoH providers that handle Firefox's. That said, the main factor here is that the track record of ISPs in the US is abysmal, whereas the current (and hopefully potential future other ones) DoH providers have committed to far stronger privacy protections.
For 2, the one thing that's missing from here is that we _know_ many ISPs are selling your data. I'm really uncertain why people are so determined to villify Cloudflare - who don't really stand to gain that much more useful info about you from this than they already have - and give a totally clear pass to their ISP despite years of proven bad behaviour. Yeah this (by default) uses CF's DoH service - note that you can change this if you want - but in my view that's strictly better than continuing to allow your ISP to to sell your browsing history.
In other words - a bit of by-default centralisation is in my view an acceptable price to pay for the increases in privacy and security (especially as it's trivial to switch away from CF if they behave badly).
A good solution would be to do DoH upgrade to their existing provider if the user already has DNS set to a non-ISP resolver (eg. Google, openDNS), only using CF as a default for ISP dns. That or racing multiple DoH providers for the first few queries to choose the fastest one for the user.
Internet gateways commonly give out the gateway's IP address as the DNS and then forward requests upstream from there. How does the application know which DNS the gateway is configured to use?
In [currently only] Chrome, it doesn't upgrade if the DNS advertised is the router. This proposed Firefox system then would default to CF [or default to the fastest one].
>who don't really stand to gain that much more useful info about you from this than they already have
that is absolutely untrue. Today they only have data for websites already using CloudFlare Services.
DoH they can info on ALL websites users for FF visit. and while their "contract" with mozilla requires they "anonymize" the data, they are admitted to collecting aggregate data which is VERY valuable in itself, plus I never trust companies when they say they will "anonymize" the data
Further I have not see what if any penalties are imposed on cloudfare for any violations of the "contract" they have with Mozilla, if there are no penalties then the contract is pointless and not an assurance of anything
As to why people villify Cloudflare, it is what CloudFlare represents that is a problem for people like me. The Internet is best serviced by decentralization. in the last 10 to 20 years we have seen and continue to see MASSIVE centralization of core infrastructure.
FF move here represents another step on that path. CloudFare already has too much of the net behind their infrastructure.
They are an inherit threat to the free and open web
I think 1 is about OS defaults, not stuff users must know to do. People knowledgeable about privacy could always bolt things on, and that's quite orthogonal to this discussion. Rather, this is all about the people who do no installation/configuration beyond an OS and a browser.
> DoH providers have committed to far stronger privacy protections.
What about DNS tampering? In many countries there are different rules for taking down a website. My ISP applies different rules than 8.8.8.8, which is handy when required by law in France but not in USA.
Effectively, government-mandated tampering will be applied with much less granularity because of centralization (or bi-centralization).
In addition to (2), I imagine it's easier to set up a completing DoH service and get it included in Firefox than an ISP that can reach a similar number of users. So it may not always be so centralized.
That doesn't work anymore. ISPs are not going to block AWS IP ranges or Azure IP ranges, etc. The cloud killed IP blocking. The pirate bay is supposed to be blocked in UK by court order, but because they use cloudflare it's still accessible and only DNS blocked.
And yet this was/is one of the justifications for implementing this.
They're not doing it in the EU because (a) there are decent privacy laws, and (b) IP addresses are (IIRC) considered personal information and so Cloudflare DoH would be responsible for keep a whole bunch of data safe. They may not want that responsibility.
This seems to (currently) be US-only because of the sucky US privacy laws.
No the justification is to make it harder for non-authoritarian countries to block websites. If China or North Korea want to block the IP range of AWS+Azure+Google that's up to their respective autocrats.
Most democratic or even hybrid regimes are not prepared for that level of absolute chaos and consequent protest if half the Internet is shut down. You can only pull that shit in a dictatorship.
Okay fair but they are two sides of the same coin. Blocking is active snooping. If an ISP knows what site you are visiting they can block the connection. In both cases the way to prevent it is to extinguish privacy leaks.
This is addressed in TFA: The fact that there are multiple problems and solving any one of them doesn't help much until they're all solved, should not be an excuse to refuse to solve any of them.
So you have a "solution" that doesn't really solve the problem, and also create a new privacy problem (now cloudflare has your data too). Hence it's actually a privacy loss.
For some (large, especially) sites, the IP address maps to the entity you're trying to contact. For others (small, especially) sites, the IP address is shared among many entities... not just shared origin hosts but also the massive reverse proxies of the world (Cloudflare, etc.).
There is an actual research on this. More than 90% of alexa's top 1 million websites (more like 95% or so) are uniquely identifiable just by IP addresses you connect to when you visit them. This is not a single IP address per website, but multiple, because websites include subresources with other IP addresses to connect to.
On top of that, there is a pressure on CDNs and clouds to make websites stick to specific IP addresses and make them blockable by IP addresses without affecting other customers. So far they have proven to not go against this pressure and even made technical solutions to aid governments to identify websites by IP addresses, in particular by fixing L7 routing layer to block domain fronting (which is important, because ESNI is basically domain fronting, but crappy, and the pressure didn't go anywhere, so there is the same pressure to make sure ESNI doesn't interfere with identification of websites you are visiting).
Also, Cloudflare does give Business and Enterprise customers their own IP addresses (although often rotated) so that these sites work with old non-SNI browsers.
DoH doesn't need to provide extra privacy to make sense (although it is a mandatory stepping stone to good privacy). It also provides a difficult to block security upgrade (as opposed to DoT, which is easy to block).
We've seen regular US ISPs hijack unencrypted DNS to insert content or replace sites entirely. We've also seen bad actors do far worse on public WiFi.
So acting like DoH is a waste of time unless every part of the privacy puzzle is online is wrong-headed. It is a huge step in the right direction for privacy, increase their costs, and will be much needed when eSNI is online. In the meantime "all" we get is a huge security improvement.
Except, not really. If you're worried about DNS tampering, DNSSEC already exists all the way up to the root servers.
If you're worried about ISPs snooping on what sites you visit, they'll continue to be able to do this even with widespread DoH/DoT and ESNI adoption. You still need to connect to an IP and TLS certs still have unique serials (most of which appear on public CT logs). Correlated over a large user population, that's more than enough to get a pretty decent, aggregate view of what sites you're browsing (certainly enough to tailor ads/marketing towards you).
As for random third party networks (e.g. Starbucks wifi), if you're not using a VPN then I don't see what expectation of privacy/security you had in the first place.
Ultimately, if you don't trust your ISP (or whatever network you happen to be connected to), the only meaningful option is a VPN. Encrypting your DNS traffic to a resolver (whether with DoH or DoT) is, at best, a very incremental improvement in the arms race. It protects users against some of the most egregious ISP abuses (assuming said ISP doesn't also spoof the cert...) at the expense of potentially misleading them into thinking they have more privacy than they actually do. In the case of DoH it will also likely inadvertently end up centralising a huge chunk of DNS lookups in to the hands of a few large corporations thanks to it being opt-out rather than opt-in. At least DoT avoids that (and offers server-to-server encryption).
Much better for users who want unfettered internet access and privacy to encrypt the whole lot with a VPN and use a resolver that validates DNSSEC. If the chain of resolvers were all DoT enabled that would definitely be a nice extra but hardly essential.
Alternatively, if you're in a country with a healthy ISP market (and government you're not afraid of), there's always the option to simply move to a provider that doesn't tamper with and monetise user traffic.
In TLS 1.3 everything sent by the server, including its certificate, is encrypted.
This is possible because of a re-ordering of considerations. It used to be that the conversation starts like this:
Client: "Hi, I want to talk to Server?"
Server: "Here's a certificate for Server, which is me"
Client: [ "Secret is 123456" encrypted using the Public Key from the certificate for Server ]
Server: [ "See, it's me" encrypted using the secret 123456 ]
But in TLS 1.3 it starts like this:
Client: "Hi, I want to talk to Server and I used ECDHE to pick this number 123"
Server: "I used ECDHE and I picked 456..." [ "I am Server, here's a Certificate for Server, and here's a signature proving the conversation we're having right now is with me, Server, which you can verify using the Public Key in that Certificate" encrypted using the secret 987654 ]
ECDHE allows Client and Server to agree the secret key 987654 even though the information they publish to agree on it (123 and 456) is public for anyone to see. Its predecessor Diffie Hellman is easier to understand if you never got past high school mathematics, so research that if you've never seen this trick before.
You'll notice this is also less round trips (so better performance over high latency links) as well as being more secure and more future-proof.
Questions I couldn’t find answers to in the post or linked info about the Trusted Resolver Program:
What’s in it for the Cloudflare & NextDNS?
Are they getting paid to handle this traffic or paying to have the opportunity to access this data?
Can users outside the US opt-in?
The comment about having “no plans” to enable this outside the USA seems a bit disingenuous. Hard to believe they built this program / feature and have no plan to eventually roll out to all users. Perhaps what they wanted to say was they have no fixed timeline for roll out to other locations.
Yes, if you press the network and proxy settings in the preferences page, you will see a DNS over HTTPS setting. You can also use this to set your own resolver in case you dont trust cloudflare.
> The comment about having “no plans” to enable this outside the USA seems a bit disingenuous
The comment actually very clearly says "we do not have plans to roll out the feature in Europe or other regions at this time".
Also I have mixed feelings about this. On one hand yeah, encryption is great and someone sitting between me and my ISP will no longer be able to monitor my DNS queries. On the other hand I don't feel like this is protecting me from anything at this time. Instead of trusting my ISP, I have to trust Cloudflare. And in the meantime my ISP still knows where I am connecting to, between looking at the IP and the SNI (they mention ESNI but we're not there yet and it still just a partial fix).
DoH (in general, not Mozilla's problem) just enables any piece of software or hardware on my network to bypass any security controls I have in place. No more filtering DNS with things like PiHole, no more blocking DNS port on your firewall. This tends to work out great for Google and any random IoT device manufacturer. I could cover this with more enterprisey setups but that's the last thing I want to do at home.
So the average user probably sees no difference either way, nothing lost, nothing gained. But for me it's a clear regression because I lose the little control I had over that traffic and I just spread more data around to yet more companies. Some may even be in legal jurisdictions that are even less trustworthy than where my ISP is located.
> DoH just enables any piece of software or hardware on my network to bypass any security controls I have in place.
I think this is an error in how you've thought about the problem. If your "security controls" depend upon other people volunteering to use some protocol then those weren't "security controls" they were more like "guidelines".
[ My local airport has a sign and a telephone so that if you've arrived with goods that are forbidden or without permission to enter the country you can call up the relevant authorities and have them come fine or arrest you. The telephone looks dusty. Do you think maybe people just decide not to call? ]
Mozilla does also have a programme https://iot.mozilla.org/ about how to design IoT devices that allow their owners to control them rather than trying to bodge things by hoping they use protocols you can intercept.
> If your "security controls" depend upon other people volunteering to use some protocol then those weren't "security controls" they were more like "guidelines".
It isn't really a matter of security controls. Anything has always been able to create an encrypted tunnel on TCP/443 and send whatever over it.
The issue is administrative cost for cooperative applications. You have a local DNS that e.g. blocks known malicious domains and has the local names for other devices on your LAN. The user of each device doesn't want to prevent this, the application developer doesn't want to prevent it, but making that happen when applications default to using a third party DNS goes from setting the DNS via DHCP to changing a separate setting in every application on every device.
The suggested solution to this is to have the local DNS resolve a canary domain in a particular way which Firefox takes as a request not to use DoH by default. That basically works, but I still don't know what they intend to do when adversarial upstream DNS servers start resolving the canary domain that way. It would also work a lot better if there was a standard canary domain instead of every application making up their own.
> If your "security controls" depend upon other people volunteering to use some protocol then those weren't "security controls" they were more like "guidelines".
It's not about volunteering. Previously I could block udp/53 and tcp/53 and be confident of the fact that no DNS look ups would happen. (DNS queries over other ports could be caught doing packet sniffing.)
Now I have to worry about DNS queries going out via HTTPS. So if I want to monitor my network for malware contacting a C&C server I have to snoop HTTPS. Which means I now have to install a web proxy and perhaps do MITM.
Previously I could 'simply' monitor DNS look ups to see if anything was trying to connect to nefarious domains.
> Previously I could block udp/53 and tcp/53 and be confident of the fact that no DNS look ups would happen. ... Now I have to worry about DNS queries going out via HTTPS.
That confidence would have been misplaced. DoH offers a standardized protocol, but it's not exactly difficult to put together a one-off interface for performing occasional remote DNS lookups over HTTPS. One could even use existing HTTPS sites for the purpose (e.g. https://ping.eu/nslookup/).
That is a good point, but it is also mostly independent from DoH, a VPN with an hardcoded IP would have worked in the same way (if you look into elusive VPNs you can also find some that work by injecting traffic into padding of another connection).
The only difference is if you are worrying about the traffic leaving your own browser and in that case you can just not enable DoH
My passive network sniffers may throw red flags on suspicious traffic which may end up being VPN. By disguising non-web traffic over the (until now) web-mostly HTTPS, it makes the job of someone who wants to be a responsible netizen and monitor their network that much harder.
I agree if the point is that this might increase the reach of such technologies. But if you are thinking about traffic coming from sources different than your browser then why would they be unable to open a connection on hardcoded IPs?
Also VPN sniffing can be arbitrarily hard, for example if I remember correctly tools like https://www.softether.org/ are designed to work around the Chinese internet firewall.
From my point of view DoH add nothing outside the browser.
So I should block outgoing TLS requests to be able to stop DoH?
Seems a bad idea....
At least with DNS I could run a local DNS server and block outgoing port 53 from anything else. Now I no longer have this option and each app gets to look up what it wants, when it wants. Sure, it's great that my ISP cannot see what's in these requests but nor can I! And it also means that any application (eg. any Google product) can query for advertising/tracking domains without me being able to do a thing about it.
It isn't solving a problem - it's creating a far, far worse one (for me).
If I have got this wrong, or there is a method around this - what is it???
Don't put devices on your network if you don't want to give them network access. And don't block technologies and protocols that help people protect themselves just because they also help devices protect themselves from you MITMing their connections. If you want to run a device reverse-engineering lab you have more work to do to break the security of a device.
Also remember that if you can break the security of a device, so could an ISP router. The correct behavior for devices is to treat the intermediate network between them and the servers they talk to as hostile.
How many people are using custom local plaintext DNS as a measure to analyze local devices on their network? How many more people are having their whole network's DNS usage analyzed by their ISP and anyone their ISP sells data to? The defaults are designed to be the right choice for people who don't change the defaults.
"The correct behavior for devices is to treat the intermediate network between them and the servers they talk to as hostile."
Thanks for this - I had not thought of that.
Looks like I'll be keeping my "smart" TV off the network forever then (my old LG used to send a network request whenever I pressed any button on the remote)! And all my Android devices, Windows 10 devices and my Apple TV and MacBook too. (This is only partially sarcasm - I can't really trust anything these days it seems...). The amount of dialling-out they all do is astronomical. The only solution appears to be going full 1980s and not being on the network. The dream is over.
At least my Raspberry Pi can be trusted. Other than the GPU chipset...
This is precisely why many of us use Linux and put up with some of the inconveniences or doing so - it’s more trustworthy. (And it gets more convenient as more people start using it.)
They sure do, but it’s a Linux instance that the manufacturer has control over rather than the user. (Which is the real problem, more than just what tech is being used.)
> treat the intermediate network between them and the servers they talk to as hostile
Unfortunately they also treat the user as hostile and untrusted. Your phone, browser, OS, or TV treat you as hostile when they send data to the manufacturer and give you no way of assessing yourself or actually controlling this. We have standards and protocols that ensure the data is kept perfectly secure and inscrutable between your device and the manufacturer but absolutely nothing is put in place to give you any control over this. Your choice is binary: use it or not. Every security decision seems to work out better for those companies than for the user.
In this case both DoH and DoT provide the required security for the users but one of them takes a little bit of control away from them.
The problem is that the device (or website) also treats the owner and legitimate user as untrusted and obfuscates the content of the traffic in a way that makes everything completely opaque for them. The device/site only trusts its manufacturer which makes any device that completely obscures its traffic from its owner feel more like a Trojan horse. This is how you end up with questionable telemetry and data leaks for example.
What's a "trustworthy" device in this circumstance? If you can never verify then it's not trust it's faith and hope.
What I want is a key to my own house, not an open door. Right now using a lot of software and IoT devices feels like buying a house but the builders keep the only key.
> Don't run devices on your network you don't trust.
This advice is about as practical as "Do not use ISPs and their forwarders that you don't trust.". Which is to say, not much. Let us know about your experience with smart TVs and similar devices, and how much you trust them.
> Don't run devices on your network you don't trust.
Oh, is that all?
How about I trust the devices until a secretary clicks on a (spear)phishing link that runs a zero-day. Then what? The host is compromised so I can no longer trust any end-device monitoring software on it, and now the network traffic is opaque.
And that doesn't even get into things like academia where students and visiting researchers bring devices of unknown providence. If if they're on DMZed networks, they could be spewing garbage onto the Internet and getting my CIDR range blacklisted.
If anything hits port 53 on the outgoing gateway, and it's not from our recursive servers, then we know that network element needs to be looked at: either it's mis-configured or malicious.
Anything that uses our recursive servers is monitored, and we can check against blacklists, either in real-time or after-the-fact through logging.
Then your security strategy definitely needs improvements, since malware often uses hardcoded IPs to bypass DNS proxying/forwarding that corporate networks use. Seriously, this argument could be used to say we should be using HTTP instead of HTTPS, but anyone doing security knows if they really need that level of introspection they need to MITM HTTPS traffic with a MITM proxy. If you care that much, you also need to MITM DoH/DoT traffic.
Given that Cisco has a major product, Umbrella, that is sold as a part of enterprise security strategy I'd say that more than the OP is considering DNS filtering / monitoring as part of a network security strategy.
> If your "security controls" depend upon other people volunteering to use some protocol then those weren't "security controls" they were more like "guidelines"
> Security controls are safeguards or countermeasures to avoid, detect, counteract, or minimize security risks to physical property, information, computer systems, or other assets. [0]
Of course it's a security control. Not a perfect one but a security control nonetheless. And every security control of today might become useless tomorrow so I don't get your point. Is a firewall a "guideline" just because I can tunnel some illegitimate traffic through an accepted port? Are your house and car door locks "guidelines" because a thief has to "volunteer" to not break/pick them or go in through the window? So you'll take them all out until you have "real" security controls? I guessed not...
As for your airport example, given that illegal activities go unnoticed and items are smuggled through customs every day you could argue that there are no security controls in place and that the airport relies on people volunteering to not break the law. But you'd be using the wrong definition and understanding of what a security control is.
As far as home security goes having DNS filtering adds a layer on top of the "nothing" you normally have. And it's a pretty good and accessible way to achieve this extra bit of security. "Not perfect" does not equal "no security". And it's not even just security: ad-filtering, parental controls, privacy, etc. are all impacted. DoH all but guarantees that you lose this control and unfortunately there's nothing ready to take its place.
Why? If you know how to run your own pihole, you know how to turn off DoH? You're not being forced into this, a default setting is getting flipped and you're entirely free to go "no thanks" and flip it back, so if you trust whoever owns the IP that you're using as real, unencrypted DNS server, then just keep using that. Same as for folks who want to keep using unencrypted emails "because encrypted mail isn't fully encrypted anyway and just makes things harder".
As tech changes, solutions change, but at least for the foreseeable future your DNS intercept will keep working just fine until everyone switches over to DoH and stops offering an opt-out.
Parsing the text helps with understanding it. And the fact that Mozilla allows me to flip back says nothing about those general cases. I do not expect everyone to give you the choice.
You may find noteworthy that my comment had 2 points. One where I don’t feel like DoH will bring much benefit in the browser today, and one where DoH in general will just give you, the user, even less control over what you’re sending out. I can’t imagine everyone giving you the option to switch, all the TRRs being actually trusted, or even being able to pick the TRR in most setups (IoT? Your random Google product?).
That's one thing, sure, but that doesn't affect the majority of sites. CF's DNS POPs are likely more dense than the great majority of service providers POPs. So using the subnet of the resolver is about as good (if not better) than having ECS info for practical purposes. (Because the client is normally going to hit the closest DNS POP to them in BGP network distance.)
I'm not a CF fanboi, in fact I think they are evil. But let's not make weak arguments. That said, yeah suppression of ECS info is a deliberate anti-competitive choice by CF. They probably have convinced themselves its about privacy, but it isn't.
The real benefit to them is, as the CDN, they get the benefit of even lower latency and even better control. With a penalty to everyone else.
It's a disgusting arrangement, and a net loss in privacy. Your ISP already knows what websites you visit, they don't need the DNS because they see the actual traffic.
I'd find it more palatable if these so-called TRR providers were required to be DNS-only. Maybe DNS + registrar.
>Your ISP already knows what websites you visit, they don't need the DNS because they see the actual traffic.
Then why were the big ISPs lobbying against this plan when proposed by Google originally? Because they truly were concerned for the welfare of the Internet as they claimed? This is a concern they've never exhibited in the past, their only demonstrated concerns have been related to their revenue streams.
Running a public DNS service allows Cloudflare and NextDNS to provide faster and smoother DNS updates to their B2B customers by avoiding third-party DNS resolvers and caches.
curious, can see the case for the capability giving advantage, but how do you think running the public service would? or do you mean competitive advantage in marketing their products?
Mozilla was founded in USA, which may be of relevance for why USA was selected as the country of launch. I don’t know anything specific about their decision, though.
it's probably because cloudflare and friends went "we want to see what hit we're taking if we do this for free for you, by only enabling this by default for the US first" or something.
After eSNI becomes mainstream, network level ad blocking will be extremely difficult. My guess is there will be a huge ad blocking subscription play in the future.
They’re usurping control and calling it a privacy enhancement so they can sell the control back to us with per user per month pricing.
Collect data of course. Mozilla is very naive to trust that they won't collect data (be it personal or otherwise). Neither they nor the enduser can ensure that.
I'm amazed noone else is asking this. CF's whole business model centres around the concept of denying website access to minorities they classify as "bots". Some big actors can afford to practice the notion of reciprocity by blocking access to Cloudflare in return — https://news.ycombinator.com/item?id=21155056 — try doing that now when you might end up blocking access to your site for all Firefox users.
People don’t take issue with DoH, they take issue with an advertising supported browser like Mozilla’s unicast (and now bicast) centralization of DNS traffic that was previously distributed.
We invented DNSCrypt. There’s also DNS over TLS. Lots of ways to encrypt DNS without centralization.
They make this about DoH when really the primary issues are with how they went about it.
DNS over TLS and DNSCrypt both depend on servers... exactly as centralized as DoH. They are just different wire protocols that in the end do the exact same thing with a centralized DNS server.
In fact, the only meaningful difference between DoH and DoT is that DoT runs on a separate port, so network operators (and ISPs) can filter it. DoT is DoH with a kill switch.
DoH can be blocked by IP addresses, DNS canary and probably SNI, while DoT by IP addresses and port number. So "DoT is DoH with a kill switch." is again nonsense.
Virtually every router on the Internet has the built-in capability to block DoT with a single configuration change, but you can attempt to create a blacklist of DoH resolvers to try to stop that, so they're totally equivalent. That's the argument you've got.
Nothing prevents Google or Cloudflare to run DoH on the same IPs as their user-facing services. Unless you are willing to block Search, for example, you might be SOL without TLS-terminating proxy.
So one is easy to block and the other is hard, requiring maintaining a blacklist and or deep packet inspection. I'll take the hard one please.
Just increase the cost/difficulty of a thing makes that thing less common. In this case that "thing" is ISPs selling highly accurate web histories to anyone who will pay. Please make that harder/more expensive, every cent of cost to the ISP is welcomed.
This is not the full picture if we are being honest with ourselves. When DoH is default on in all browsers, the masses will be talking to 2 or 3 companies. Sure, they can change what server they talk to, but we all know that most people won't even think about it. DoT implemented on all DNS servers would keep control as distributed as it has been up until now. Until the root serves support DoT, which I doubt they ever will, there will always be weak links. This includes from Cloudflare, Mozilla and others talking to the root servers. I am not trying to convince anyone of anything. This is a very polarizing topic and has been every time it is discussed here and other news aggregators. The best I can do is educate people that I care about so they can make an informed decision.
People keep talking past each other on this because somehow DoH got conflated with Cloudflare.
DoH is a protocol. It has better security than unencrypted DNS. (So do several others, like DNSCurve, DNSCrypt, or routing your DNS queries over a VPN.)
The objection people have is not that it's encrypted, it's that Mozilla implemented it in the browser instead of the OS and thereby ignores the DNS you configured in your OS. And even that is fine as a setting you can enable, but it's problematic as the default. Both because it's administratively burdensome to change a setting in every application on every device if you want to use your own, and because of the second order effect of that, which is that hardly anybody will change it and then DNS becomes centralized to whatever is the default in the browsers.
If you're worried about your ISP snooping on you and tampering with DNS records, the tools we have today already offer better privacy and trust than DoH, DoT, DNSCurve or DNSCrypt.
Just use a DNSSEC capable resolver in combination with a VPN. All other options today are effectively theater.
DNSSEC is the least useful of the lot. It only authenticates, doesn't encrypt, so it's not enough on its own, you have to use it in combination with a VPN. But the VPN would be enough on its own between the client and the recursive DNS, since it does both.
Between the recursive and authoritative DNS the VPN wouldn't exist, but if the attacker is there then DNSSEC is in trouble again because it still doesn't encrypt (no confidentiality). What can be used on that path is DNSCurve, because it does encrypt even where there isn't a VPN.
The majority of domains also aren't DNSSEC signed anyway, so it doesn't even authenticate them.
You're conflating privacy with trust. DNSSEC gives you trust, the VPN gives you "last mile" privacy. DoH is only designed for last mile so useless in encrypting the resolver chain between you and the root servers.
Currently there is no way to get a fully encrypted chain (the root servers would need to support DoT or something similar and they don't nor are there any plans for them to do so afaik).
So the best (form a privacy and trust PoV) you can achieve is as I've outlined: VPN together with a DNSSEC resolver (with verification enabled). Over time you can hope for DoT to gain wider adoption so more and more of the upstream resolver chain is encrypted.
DoH mitigates the "ISP selling your DNS data" threat, which practically everyone in the US faces, without forcing all your traffic onto a VPN, which not everyone wants. Meanwhile: practically no important zones are signed, so apart from the fact that DNSSEC does nothing to improve privacy, it's also not useful. DNSSEC is moribund; taking steps to enable it is a waste of time.
DoT would also mitigate it in a similar fashion. In both cases mitigate doesn't really have much meaning since, sans VPN, ISPs that are inclined to do so will quite happily continue to find ways to infer where you're browsing to (IP address and CT log correlation being the obvious choices). Ergo, if last mile privacy is you're issue, the best bet is a VPN or some improved regulation so that consumers have a choice if they want an ISP that doesn't spy on them.
DoT and DoH have virtually identical service models. The practical difference between the two is that DoT deliberately runs on a nonstandard port, so that network operators can filter it. It's not an exaggeration to say that DoT is simply DoH with a network kill switch.
When was the last time port 995 or 993 were blocked? If the same adoption happened with DoT, ISPs wouldn't have the option - customers wouldn't accept it.
Confidentiality and authentication are two different things, but the things that provide confidentiality here also provide authentication. DNSSEC only provides authentication, so then you need something else to provide confidentiality at every point in the path. At which point you would also have authentication at every point in the path, so what does that leave for DNSSEC to do?
> DoH is only designed for last mile so useless in encrypting the resolver chain between you and the root servers.
This is true. DoH isn't the one to use between recursive and authoritative DNS servers.
> Currently there is no way to get a fully encrypted chain (the root servers would need to support DoT or something similar and they don't nor are there any plans for them to do so afaik).
DoT has a similar drawback as DoH between recursive and authoritative servers. The session establishment is expensive (more round trips, higher latency). That's not so bad for the link between the client and the recursive DNS, because you create a session once and use it for all your queries. It stinks between recursive and authoritative servers because the recursive server would need a new session for each authoritative server -- and a single recursive query can often require contacting three or more authoritative servers.
Fortunately DNSCurve has lower latency and can be used between any pair of recursive and authoritative servers that support it.
The root not supporting DNSCurve is an issue, but it has an obvious long-term solution (have the root start supporting DNSCurve), and in the meantime the recursive resolver could validate only the root with DNSSEC. The lack of privacy is much less impactful for TLD queries -- a query for your-local-oncologist.com tells an observer much more than a query for .com. Then if DNSCurve is used for the rest of the chain after the root, you have one authentication or the other for the full chain and privacy for all but the TLD query. You also then don't need any large DNSSEC records in the authoritative servers that support DNSCurve, which would otherwise be a DDoS vector.
> So the best (form a privacy and trust PoV) you can achieve is as I've outlined: VPN together with a DNSSEC resolver (with verification enabled).
I still don't see what that's even supposed to be adding over the VPN right now. The VPN handles the link between the client and the recursive resolver. You can only get authentication between recursive and authoritative servers for domains whose authoritative servers support some authentication, but hardly any of them support any authentication right now, and if you're going to add one it makes more sense for it to be DNSCurve than DNSSEC because it provides confidentiality in addition to authentication and isn't a DDoS vector.
DNSCurve sounds quite nice (I'm not at all familiar with it tbh). I agree something along those lines with DNSSEC for the last hop to the root would do it.
To be honest my main gripe is with DoH. For non-last-mile privacy/trust, there are indeed many suitable ways to tackle it.
While that is true, it would be much easier to get DoT deployed at scale. During DNS Flag Day of 2019 [1] a significant number of recursive DNS servers around the world started properly supporting EDNS0 and several other modern features of DNS. In most cases, it was just application version updates or configuration changes. Most of the popular and widely deployed recursive DNS servers already support DoT, which means that a similar effort could be made to enable DoT. AFAIK none or few of the popular recursive DNS servers support DoH today natively. It would be significantly easier to get DoT enabled en-mass. People are much more open to making a configuration change if that is the least path of resistance.
>> We invented DNSCrypt. There’s also DNS over TLS. Lots of ways to encrypt DNS without centralization.
Ummm so what’s the downside then? Are those services arcane and hard to use and utterly forbidding blackest black magic, like almost all crypto stuff?
If you’re thinking browser users will just do this then that then this and x and y and z to “get dns crypto going”, then I’ll take Mozilla’s “it just works” approach.
It’s a much much better approach for the browsers to implement it rather than wait for everyone’s operating system to implement secure dns because that’ll happen .... well I can’t imagine any time in the future you could say everyone’s OS is using crypto DNS, whereas if browsers implement it for themselves, instant massive adoption.
Not sure what any of your reply means. Adding OS support isn’t required. People just run a local resolver that supports these things. No different than any other application. Nothing arcane. Certainly no more than HTTP and SSL.
>> People just run a local resolver that’s support’s these things.
Nowhere do “people just run a local resolver”. Grandma and aunty Beryl certainly don’t, nor does any other ordinary person. If you want secure DNS you have to build it in to the browser.
Only systems people think that this is the sort of thing that ordinary people do.
Not true. In the default case, Grandma's wifi router is just passing along -- via DHCP -- the IP address of the cable company's DNS resolver to Grandma's computer. Which the wifi router itself probably obtained via DHCP or a similar mechanism from the modem. This is in no sense a "local DNS resolver."
If Grandma has a grandchild that knows how to set up a PiHole, it's a different story. But that's certainly not the majority of Grandmas or the majority of wifi routers.
Basically, make use-application-dns.net. return an error (any kind will do). Filter it in your recursor for example.
Having the browser change a fundamental behaviour that used to stand for decades is highly problematic. If nothing else, it is the network administrator who should have the final say on WHEN (if ever) DoH will get deployed inside their network.
>Having the browser change a fundamental behaviour that used to stand for decades is highly problematic.
No, this is far too broad of a statement. Browsers pushing for TLS, deprecating the old SSL versions and now the old TLS versions, deprecating SHA1 use in certificates, going from quirksmode to a living html standard (not without problems such as Google's over-influence), etc all have been a net positive, but there was breakage too.
Now, DNS - a really antiquated protocol written at a time when security played no role and everybody was assumed to be a good actor and (next to) nobody bought shit online or banked online or dated online or got medical advise online - is somehow the holy grail that MUST NEVER change? Because... "it works" (only superficially, without proper security) and status quo. I don't buy it.
We may discuss DNS and alternatives/add-ons (such as DoH, DoTLS, DNSSEC, DNSCrypt, etc) and their pros and cons, but rejecting any kind of innovation isn't something I am willing to do.
> but rejecting any kind of innovation isn't something I am willing to do.
I don't think the post you're replying to is really saying "no innovation". I think it's more subtle.
The "problem" with DoH is that you need to look at it with several different hats, and I feel very few people make it clear how they're complaining about DoH.
* From a consumer perspective DoH is a good thing (mostly)
* From an traditional/enterprise/business-like environment perspective it's inserting itself in the middle of the stack and may cause headaches with a few things (not limited to leaking internal names to external resolvers), unless it's just blanket disabled/forced to a local server (which may not always be practical for different reasons) - currently
Ultimately who do we have to blame for this but ourselves? Organisations have tried to get encrypted DNS off the ground in traditional DNS infrastructure and clearly failed to meet the required timeline.
I personally feel like the problem, just like with IPv4, is that traditional DNS infrastructure is "fine" (i.e. it works). We don't have a great motivation but we do have fear of breaking the many many many boxes which are un-upgradeable/critical.
The elephant in the room is that many networks need to have content filtering, and you are proposing nothing useful. DoH torpedoes content filtering to its very core and, fortunately, the knob Mozilla provides can (hopefully) be utilized. That's all there's to it.
>The elephant in the room is that many networks need to have content filtering
First of all, we're talking about domain filtering, not content filtering.
And no, they want domain filtering, hardly anybody needs it, and there are better solutions than NXDOMAIN, such as actual content filters.
>and you are proposing nothing useful.
Why would I need to provide "something useful"? mozilla already described the many ways this can be disabled, from browser preferences, to automated checks for known disable-me domains, etc.
I need domain filtering: if the domain serves malware I want to block it, not just the known malware coming from it. If a domain serves porn, I want to block it on my kids computers (and mine) not just the content that is recognisable as porn. If a domain is used by malware I want to block it, and probably use the domain to determine the server, and block that too (too because the domain can move IP).
All of that can be implemented on the client (e.g. as a browser extension) without breaking the Internet. That's the only reliable way to do it anyway. MITM DNS filtering is easily bypassed and only effective against lazy malware.
How about wanting to filter advertising, or filter content for myself - I block imgur via DNS for example, or block domains used by trackers and malware creators?
This logic makes no sense to me. Can you imagine if AT&T or Spectrum made a statement like this?
The “network administrator” is an untrusted 3rd party who should have basically 0 say in how my device operates.
The device administrator, ie the owner of the machine, is the one who should have the final say over when DoH is used. The use-application-dns record is for businesses that want an easy way to stop DoH on machines they administer. If random “network admins” start deploying it as you say then Mozilla will have no choice but to ignore the record entirely.
So what if I run a Pihole at home as a DNS server and want to stop being able to resolve various domains? I would like to know how to stop all devices (actually worse, individual applications!) on my network deciding to DoH of their own accord (and therefore bypassing my local DNS server).
This kind of centralised ability to block DoH is very useful to me.
* On devices that you own and control you don't need a network level control like this except for convenience. This is when you should be applying the override record.
* On devices that you do not own or control (family/friends/guests) disabling DoH makes you the malicious network operator. Connecting to your Wi-Fi doesn't make you trusted in any sense of the word.
* On devices that you own but do not control (Google Home/Alexa) you make a valid point that techie types have been able to take some level of control by exploiting the fact that DNS is an unencrypted "hole" in the security of the device. You would have a lot more control if the HTTP traffic they sent was unencrypted and inspectable/modifiable but that doesn't mean devices shouldn't be allowed to use HTTPS without your approval.
Thanks. Not to be argumentative, but I find it odd/interesting that guests connecting to my WiFi and using my DNS set up makes me a "malicious network operator" in your eyes. That's a very odd view of the world in my opinion, as it is my WiFi and DNS set up.
That's like saying that me stopping guests taking photos of my daily activities (showering, using the toilet) whilst in my house is a malicious behaviour too. I suppose I should let them post the photos off to whomever they choose?
If someone is in my house and using my WiFi, I don't want their device looking up domains that I choose to block. How do I know that their device is not recording its surroundings and sending them off to the said domain? How do I know that my guest is not up to nefarious/illegal activity using domains that I have blocked? I would be the one prosecuted due to the IP address = a person approach by the law in most circumstances (should they ever deduce the requested domains from the DoH set up). Being that the DoH provider is under law, I am pretty sure that the DoH will have to hand over any records they have, which will lead it back to me and my network.
And then once again we are stuck in a situation where I cannot control what domains are being looked up by devices and applications on my network. My devices are no longer mine. I have handed off control to some company the other side of the planet with employees I will never meet.
How do I stop the 5+ tracking domains that the Instagram app uses on my wife's iPhone, for example? Am I a malicious network operator for stopping that garbage being sent off?
> I cannot control what domains are being looked up by devices and applications on my network.
This is kinda the point. For devices you own you have that control by the virtue of being the device admin. Other people's devices are a different story. You are free to have an acceptable use policy on your own network and require traffic to flow through a proxy or whatever but if you do it without their knowledge or consent you're the bad guy.
How pissed would you be if Xfinity just up and blocked random sites like this?
(sibebar: Just from a politeness perspective why would you give your guests anything other than a clean path to the public internet ?)
> That's like saying that me stopping guests taking photos of my daily activities
Having a rule that applies to your guests -- totally cool. Silently disabling their camera without their consent once they come through your door -- not cool.
> Am I a malicious network operator for stopping that garbage being sent off?
I mean you're modifying the traffic coming off of someone else's device without their knowledge or consent. I would be pissed if by husband did something like this without asking -- leaving me to debug why some sites are mysteriously broken.
I'm _maliciously_ stopping my kids Android apps from connecting to tracking and malware domains. What a tyrant I am - I should have over control to a third-party for profit company??!?
Of note: PiHole supports DoH, so you point your DoH supporting applications at it. If your OS gets around to adding DoH support you can point your entire OS at it and disable DoH in applications, but until then you'll have to do things the hard way.
At present though devices on the network all for DNS and my network says "use pihole" but applications that implement DoH never ask the network, so I have to have access to all the applications (including those from bad actors).
I block MS telemetry domains for example, where's the config for me to stop them using DoH; what about the trackers on my TV?
Now I need to configure every device - that's capable of using Firefox - rather than configuring the network. Presumably in short shrift there'll be no way to block Google advertising. I guess Google will get their return on funding Firefox.
AT&T and Spectrum do not administer your home network, you do. You have the freedom to configure whatever DNS settings you want; if you wish to use their DNS servers you may; if you wish not to, then you may not.
DoH is a non-solution to a non-problem which makes privacy strictly worse by leaking information to Cloudflare in addition to one's ISP.
You are a client on AT&T and Spectrum's network. Just because you turn on a router and set up NAT doesn't make this fact any less true. At some point your internet traffic is going to flow AT&T's network where they are the administrators and are free to apply whatever network policy they see fit.
DoH and DoT is a solution to the problem of sending your DNS requests unencrypted, leaking them to everyone in the process, and then opening the door to any malicious network operator in between you and your DNS server the ability to modify the response in-flight.
Your ISP can and should provide DoH servers. Your local network is free to do the same.
I agree with you: your local network is free to set up a resolver using DoH (or DoT, which is far more sane than an entire HTTPS connexion). That's the correct place for it to live, or possibly at the individual device level.
It is 100% not the place of an application to meddle with network services, particularly not by default.
Has anyone verified that this actually works? My company's DNS administrators have already made this change. use-application-dns.net returns SERVFAIL when I run "dig" on my machine on the corporate network.
But if I enable DNS over HTTPS in Firefox, it very clearly still uses the Cloudflare resolvers. We have some split-horizon zones set up (resolve to 10.x IP's internally, and public IP's externally). When I tick the DoH box, Firefox starts resolving the public IP, verified in the Dev Tools network pane.
I'd guess that the overwhelming majority of Mozilla's users do not have a "network administrator" looking after issues like this for them. All they have is an ISP, and the ISP is not on the user's side.
My point is that the definition of "network administrator" is wider than the corporate network administrator vision the phrase evokes.
A quick search shows me a number of parental control features in routers that use OpenDNS. All of the parents using those features would be "network administrators", too.
I think more people are "network administrators" than the average HN reader realizes.
If they do that, Mozilla will probably immediately update the check or remove it all together.
I don't understand why systems administrators don't just use their existing policy management to disable DoH if it really causes an issue. There's a group policy specifically for DNS over HTTPS [1]
The only reason I can think of is that they can't because of BYOD or Firefox being part of the company's dark IT. The DNS workaround doesn't help much in those cases because the underlying problem is a lack of oversight, not an issue with Firefox.
My feeling on this is that it's a pretty imperfect solution but unsurprising that the browser manufacturers are pushing it forward given ISPs dragging their heels on DoT.
We saw the same problem with TLS. Until the browser makers started pushing it and Let's encrypt made it simple/free the take up of TLS was patchy at best.
This will have negative effects on tools that use DNS for blocking/monitoring, but then those were a hack at best. If you want to understand the traffic flowing over your network, you need to invest in interception and parsing.
WTH does DoT adoption by ISPs have to do with that?!
One can run their own DNS recursive resolver-cache perfectly fine on their own hosts, or at the network edge, without relying on ISPs.
Better yet: Since the Root zone and TLD zone DNS servers change only seldomly, you can prefetch and cache them locally just fine, and upon resolving a DNS skip two recursion steps.
Apart from doing DPS, then ISPs will not "see" DNS queries, thus bypassing the privacy concerns of that.
That's not a good counterargument. Why you ask? Because that's something that OS vendors could easily and trivially deploy with only minimal effort.
For example on Linux you could do this with running a localhost instance of unbound, and having a DHCP client hook script updating unbound's configuration for domain specific authorative DNS servers based on the DHCP options for nameserver and domain name.
Just put that as out-of-the-box setup into default Linux distributions' installation: Not only does this greatly enhance privacy. It also prevents enterprise information leakage, and every program on the system is going to benefit from it. Not just the browser.
DoH is a clusterfuck of stupid. There's not one single redeeming quality about it. Everything positive it promises to do has been already solved in a far better manner by earlier developments. And it comes with the penality of concentration of failure points.
In the best case scenario it doesn't impair your privacy.
In the worst case scenario, all the DoH resolver operators in the U.S. will get FISA court orders – including a gag order – to install boxes helpfully provided by some three-letter-agency that monitor all incoming and outgoing traffic of their resolvers; getting the DNS queries/responses in the clear would be nice, but they don't really need it, for the resolvers provide some nicely observable traffic hub on where it's super easy to time correlate outgoing DNS resolver queries to incoming DoH requests.
And don't even believe that DoH requests would be indistinguishable from "regular" HTTPS traffic! Unless you're running into an DNS record that's been overloaded with everything DNSSEC offers the bandwidth requirements of DNS are fairly balanced in both directions. Plus, the amount of data transferred via DoH is more or less the net size of the final DNS query and request combined. So either you pad DoH for the worst case scenario size, or you have a pretty well readable side channel.
No matter from which angle you look at it, DoH makes no fucking sense whatsoever. It's just stupid, if not malicious.
I like how someone on HN tells you that ordinary users have no idea how to set up their own DNS servers and you respond with how Linux users can set up unbound. Like, well argued!
There is also something poetic about how the people that know how and are inclined to set up their own unbound servers on their laptops are getting worse security than everyone else. That sparks joy for me.
The underlying issue is that a DoH provider can craft the DNS answers individual users get if it wants to.
Think about it: a Firefox DoH user could get different DNS answers than other apps get on the same machine using standard DNS on port 53, if Google or Cloudflare wanted to, because they’re essentially talking to different versions of the internet.
Remember, all of the properties that allows HTTPS to be trackable—cookies, fingerprinting and the rest—is in play for DNS over HTTPS as well. DoT doesn’t allow for that.
If all these providers wanted was encrypted DNS, they’d be pushing DNS over TLS, which is just standard DNS using TLS as the transport. Sure, it uses port 853, but given time, enterprises and other security-conscious organizations would have adjusted, especially if the entire DNS ecosystem got behind it.
But because Google, Cloudflare and NextDNS see an opportunity of some kind, they are pushing for DoH.
The DNS is an open, global, distributed hierarchical database; DoH starts to break this because apps can bypass most of this and that’s not how the internet was designed to work.
The same way Gmail broke the model of federated SMTP servers to a large extent, there’s the potential for the major DoH providers to do the same to DNS.
Imagine if Cloudflare decided to block certain DNS records from their users. Certain services that worked fine pre-DoH would break.
> Think about it: a Firefox DoH user could get different DNS answers than other apps get on the same machine using standard DNS on port 53, if Google or Cloudflare wanted to, because they’re essentially talking to different versions of the internet.
There's no difference that a DNS server can see between a browser on your computer making a DNS request vs. any other app. But if the browser is using DoH and other apps don't, then it can tell.
Not really. It's an argument for the industry moving to something sensible; not "split braining" low level infrastructure by shoehorning some of it into HTTP, apps and a handful of centralised coporations who claim to play a little nicer than telcos.
I posted the article Centralised DoH is bad for Privacy, in 2019 and beyond to HN nearly a week ago [1].
Here’s the money quote:
DNS over HTTPS however neatly separates out each device (and even each individual application on that device) to a separate query stream. This alone is worrying, as we now have individual users’ queries, but the TLS that underlies HTTPS also typically uses TLS Resumption which offers even further tracking capabilities.
Yes, in the hypothetical case that some agency is compelling CloudFlare (and/or NextDNS) to provide ongoing real-time decryption, which would be somewhat unprecedented: not entirely dissimilar to things which have been publicly reported before, but not the same either. In the more likely case that that isn't happening, you make those agencies' lives a lot harder.
> Cloudflare does not block or filter content through the Cloudflare Resolver for Firefox. As part of its agreement with Mozilla, Cloudflare is providing only direct DNS resolution. If Cloudflare were to receive written requests from law enforcement and government agencies to block access to domains or content through the Cloudflare resolver for Firefox, Cloudflare would, in consultation with Mozilla, exhaust our legal remedies before complying with such a request. We also commit to documenting any government request to block access in our semi-annual transparency report, unless legally prohibited from doing so.
https://developers.cloudflare.com/1.1.1.1/commitment-to-priv....
Normal DNS over UDP can also contain arbitrary data, which completely hypothetcally could be used to send identifying data about the client. E.g. https://unit42.paloaltonetworks.com/dns-tunneling-how-dns-ca... But that's not really a strike against the protocol, that would be a fault of the implementation.
In order for Cloudflare (or anyone) to be a part of this program they have to comply with a particular set of rules.
Limiting data. Your DNS data can reveal a lot of sensitive information about you, and currently DNS providers aren’t subject to any limits on what they can do with that data; we want to change that. Our policy requires that your data will only be used for the purpose of operating the service, must not be retained for longer than 24 hours, and cannot be sold, shared, or licensed to other parties.
Yes, governments can secret around this with intelligence orders, just like they can do with any of the ISPs that will keep all of the data indefinitely instead of for 24 hours.
I've found this harder and harder over the years. My usual MOD was installing and configuring the caching-nameserver BIND package in rpm-based RHEL-downstream distros and MaraDNS in everything else. I've just kind of given up because reasons but I'm still very supportive of any of these kinds of efforts.
It removes a 3rd party that is a juicy target for TLAs. There is only you and the remote hosts that you're talking to.
But yes, it would be really nice if we also had encryption between recursive resolvers and authoritative servers to remove the last place where they could harvest data.
Kind of sad when you need a private company to give your citizens the basic privacy they want (doubly so when you have to simply trust said company that the partners they are working with are honest). Maybe the US's privacy laws need a 21st Century make over?
I think part of the negativity you see is network admins working in businesses.
Their opinion is that it's a way for people to get around corporate firewalls. Kinda blind to the idea that if a browser can implement DNS over HTTPS then anything can.
Especially since there's some of ways that Mozilla have implemented for a local area DNS server to override its settings.
There's also another camp, if you remember the "internet villain of the year" award that Mozilla got for DNS over HTTPS from an ISP industry group.
Of course their argument was parental controls being made ineffective.
But of course it's transparent that this was a gambit to change public opinion so they can keep collecting browsing data to sell.
Interesting to note they went after Mozilla not Google who are also implementing it.
But really the messed up thing is that this improves privacy for the vast majority of users. Especially those people around the world where searching the wrong thing up online can lead to imprisonment or worse.
This kind of thing is a privacy improvement for millions.
And I find it shocking that people in Business IT care more about managing their corporate devices than the good of the majority of internet users.
I'm not a network admin working in a business, but I am the network admin of my home network, and I really do not want applications starting to effectively contain their own VPN clients and subverting my control.
Tunneling DNS inside HTTPS effectively forms part of a VPN already (and I wonder when Mozilla will decide to also stuff the rest of the traffic through...)
DNS-based blocking is not perfect, but is currently still very powerful for things like adblocking.
You're basically saying that Firefox is now behaving like malware, which I agree with...
Windows 10's telemetry is also another piece of software which has started to become hostile in this manner, hardcoding IPs and such.
For home network operators who value controlling the name resolution of devices they 'own' MITM won't be enough once embedded device manufacturers start using certificate pinning w/ DoH.
> I wonder when Mozilla will decide to also stuff the rest of the traffic through
Mozilla has recently begun offering an integrated VPN with Firefox, though unlike DoH that has a monthly subscription fee (hell, I don't blame them for wanting to diversify their revenue). The partner in that case is Mullvad.
> You're basically saying that Firefox is now behaving like malware
This is hyperbole. End users should look out for their own best interests by using any means necessary, which includes hiding as much as they can from the network. If the network doesn't like that, then it has the choice not to allow that user to attach a device to the network.
It's the inherent problem of your network position being between a device and the outside internet, the same position that browser activity-selling, website blocking ISPs are. The only difference is that previously, DNS would be unencrypted so you could DPI dns and/or block DNS requests going outside of your custom resolver. If an attacker wanted to hide DNS previously, they would need a hard-coded IP address to send encrypted requests to; now they can use big providers like CF/Google for DoH.
If you don't want DoH, you are not forced to use it. Yes its enabled by default, but it doesn't mean you cannot go into the settings menu and deactivate it.
Hmm, unless you're trying to control what comes in/out your home network .. in which case you're screwed. But you can switch it off in your own browser.
I was a happy pihole user. I could choose to allow DNS lookups, and blacklist using OpenDNS. If I install Firefox at home, then I can't block problematic sites; and Cloudflare will use this to sell the idea to advertiser for TVs and such, so it looks like Google/Cloudflare just used Firefox to obviate ad blocking.
I also use PiHole at home, and lets be honest, if we know how to setup a PiHole, deactivating Firefox DoH is not going to be a problem for us.
DoH is not meant for us, it is meant for the average people who have no tech background. Just because it will cost us a few minutes to configure, we shouldn't deny the overall benefit it will bring to most.
> Their opinion is that it's a way for people to get around corporate firewalls. Kinda blind to the idea that if a browser can implement DNS over HTTPS then anything can.
Thats not the problem. If more application folow Firefox, and do DNS on their own, corporate applications and sites will stop working, and IT will get the blame.
Now that it's just firefox, ok, but if other app will follow the lead, we will constantly have to play whack a mole, why someone doesn't resolve correctly.
How do I debug problems ?
Is there a tool (something like dig), i can use to see, how will Firefox resolve a domain ?
Where i work we don't block anything on our firewall, but we have plenty of services only exposed on internal DNS. Not to mention, we have to a lot of times replicate environment that is similar to clients, so I often create zones, where people can VPN in, and have similar DNS resolution as the target. Each app doing its own DNS will make that harder.
> Especially those people around the world where searching the wrong thing up online can lead to imprisonment or worse
That would be true, if Mozilla rolled this out worldwide, but its US only.
Also right now there are bazillion ISP with bazillion DNS servers.
There are very few DOH DNS providers that Mozilla endorses, so if majority of "privacy" conscious people will start using them, it will become that more valuable for various bad actors to compromise them.
Right now there are so many ISP's with their own DNS's that even if all of them were selling the data, just finding them all and buying their data would be huge task.
This is another centralization of previously decentralized service. (like it happened with email)
Honestly I think that in the long run, this will be worse for privacy that we have now.
My main gripe is that before DoH, setting a custom DNS via DHCP was enough to get all devices on a network and all applications on these devices to use a custom DNS.
Now we are headed to a future where each software vendor decides how to make DNS queries. I can predict that all of them will apply their own custom heuristics to detect things like split-horizon.
> before DoH, setting a custom DNS via DHCP was enough
That ship had already sailed. You also have to run your own DNS, allow DNS egress only from your own DNS, and DNAT the rest back to yours in order to un-break all the things with hard-coded resolvers.
Same with NTP surprisingly. Literally everything I have talks to a NTP server once in a while, but only Linux machines actually ask the network's NTP servers.
Lots of embedded Linux devices have hardcoded NTP servers. Was caught by surprise at this after I'd segregated a bunch of stuff to have no Internet access.
We are headed toward that future because the broader network has proven that it cannot be trusted; it should come as no surprise that user agents would develop defense mechanisms. If this is another step toward ensuring that ISPs are nothing but dumb pipes, I welcome it.
It started with PCI compliance. Next up was Corporate IT making sure idiots weren't signing up for Dropbox with their LAN password. Schools: Well, they always used proxies with no expectation of privacy whatsoever so traffic inspection was nothing new.
In 5 years TLS-recryption -- whether through software or a hardware middlebox -- will be as ubiquitous as a NAT firewall is now. The only question is if the keys will be in the hands of the consumer or in escrow with Big Gov.
The idea that anyone in their right mind would allow uninspectable traffic to egress their network is beyond ridiculous. I'm glad that DoH is making people realize that.
The problem I have with DNS over HTTPS is that it's something implemented in the browser, that ignores the DNS configuration of your PC and your local network. That has some implication, for example you are unable to access local hosts on your network by their hostname (for example https://fileserver). Also you have a solution that works only on one program, while the rest of the system DNS requests remain unencrypted, that is bad.
Browsers shouldn't implement DNS theirself, and should use operating system APIs to do all the DNS queries. That is how networks work, and doing that differently creates problems (imagine if every program has its implementation of DNS over HTTPS, you have to configure correctly the DNS server in each of them, and good luck debugging it when one implementation is broken...)
As a technical motivation, HTTPS in an high level protocol, and using it for DNS is kind an overhead. We already have DNS over TLS that is a standadized protocol, that can be used, and that the operating systems are starting to implement.
I use DNS over TLS in my local network, but rather than having configured all the computers to use it I have configured a local DNS server that encrypts the requests, for every host in the network, and also filters trackers and ad servers. Thus I don't want Firefox to mess aroung with my local network configuration that is fine.
For one, it’s ironically first being deployed in countries where DNS manipulation by the government isn’t happening (US first generally), but Google has competitive concerns with ISPs getting ad targeting data. I feel like defending against oppressive governments is being used more as an excuse than a driving motivation. The primary concern seems to be that Google really wants to protect its monopoly, and Firefox, as a major benefactor of Google money, has fallen in line.
And second, as an IT admin, I’m annoyed web browsers keep trying to develop new ways to bypass my network security.
Decades of experience have told me that whenever some big organisation wants to do something in the name of "security", it's almost always an excuse to remove freedom and force their control over everyone.
Yes, that includes oppressive governments too... but I hardly think that even more centralisation is the solution.
The old security vs freedom quote is surprisingly relevant in so many situations today.
This argument can be applied to the encouraging the rollout of HSTS and HTTPS by firefox and google, which cant be disabled very easily by administrators.
But Mozilla's justification tables around making security better for all users by dictating default settings that are expected not to change. So, defaults need to achieve the goals.
There are dozens, and yet Mozilla chooses the same company that forces Google captcha on site visitors that try to protect their privacy by using a VPN or Tor?
Or in other words, DoH works better on hostile networks because it looks like just one more HTTPS connection.
That's an intentional design feature. You're attempting to intercept traffic, and any mechanism you could use to do so "transparently" could be used by any hostile network to do so.
You can still intercept traffic from cooperating devices if you want, just not transparently. That's a feature, not a bug, and the Internet will be better for it.
Right, but I do think this is better handled at the OS layer. Hardcoding everyone to route through Cloudflare is a hardly a net win, and might be better or worse than your ISP depending on who and where you are.
I'm not against DOH but there are definitely some downsides. For example, your token does not get reset on network changes. This means your DNS provider can track your DNS requests across networks, including VPNs.
With normal DNS anyone in the request chain can see a stream of DNS requests but there is no context. By the time the request is one or two hops from you it will be interwoven with tens of thousands of other requests making it impossible to know which one came from who.
With DOH the DNS provider will have a unique identifier to correlate requests back to a specific system/user. Google offers one of the most used DNS services, with DOH they will be able to track all DNS requests you make even if you turn on a VPN.
It added yet another thing I have to implement, test and maintain through whatever changes they decide to make.
Nothing like adding extra work for every enterprise IT team to make new friends.
There are also some massive security issues with making all https traffic blind that making only the data blind didn't create - like the ability to blackhole known unsafe domains as they appear.
> DNS is the primary way governments control and spy on web access.
And DoH will enable every device you own to continue spying on you for the benefit of corporations.
DNS is the last bastion of preventing devices I can't sufficiently control from spying on me. I use DNS filtering to block their tracking domains. I use my firewall to prevent devices from accessing DNS resolvers I don't control.
DoH takes those options away from me. Ridiculously, in the name of privacy. Ha!
Unfortunately, the battle was lost the moment someone created a DoH implementation. It hardly matters what the browsers do. All the other things I don't want to have DoH will eventually implement it. And they won't respect use-application-dns.net or whatever other frameworks Mozilla comes up with for controlling DoH at the network level.
(Also, does anyone really believe that governments, ISPs, and public DNS resolvers aren't going to disable DoH with use-application-dns.net? I'm sure whomever came up with DoH in the first place had great intentions but the end result is a disaster that will cause more harm than benefit)
So your point is that your attack model was that makers of malwareApp would try to connect to malwareapp.net instead of a random IP?
If you are worried about traffic in the browser you can not enable it, it you are worried about anything else then VPNs were already a thing since some time ago.
I suppose my model is that every connected device and app, every web site someone visits, is malware. My household is full of things collecting data and passing it on to entities I don't wish to share that data with.
How do I stop that when my ability to control what happens on my own network has been been reduced to Can access the Internet over 443, or not?
My question is how does DoH contributes to that in practice/theory. If a malicious/incompetent app/device wants to access random servers with DoH they would need to include a DoH implementation and then DoH offer nothing more than VPNs. In this context I do not understand if you are worried to have wireguard installed on your connected devices.
If you are talking about Firefox itself, then disable it.
I sympathize with wanting more control, but I do not understand how DoH changes things in a household settings.
(I am assuming your is not a corporate point of view, in that case I agree that DoH might cause significant headaches)
> I do not understand how DoH changes things in a household settings.
Imagine you run a PiHole or use a service like OpenDNS. It doesn't matter what you've chosen to use or block, what matters is that you've made a choice to utilize DNS filtering for certain things.
You soon discover that some apps and devices don't respect your DNS decisions. They make money or derive other value through communications that are blocked by certain DNS-based filters, so they query 8.8.8.8 or some other DNS directly. You figure out how to make them respect your choice, through a combination of restricting DNS egress and DNAT at the router, and all is well again.
Mozilla and Chrome come along with DoH. That's alright. You can configure them not to. There's the canary domain, so you don't even need to configure browsers manually, tho I expect the canary will eventually go away -- it is destined to be "abused" by every entity in a position to get away with it.
What's going to come next is real the problem: Every entity which can benefit from being able to bypass DNS filters is going to move to DoH. It's in their best interests to do so. They don't need to respect the canary. You won't even be able to tell what they're doing because everything is encrypted with TLS and have pinned their certificates.
App will do it. Embedded devices will do it. Actual malware will do it.
This outcome is inevitable and that is my objection to the mere existence of DoH.
My question is how is DoH different from contacting 1.1.1.1 over https and asking for DNS information without the DNS protocols.
I understand why people do not want this and want control over their own network, I find that a commendable goal. I do not understand how DoH specifically introduces anything new since you could already get DNS data from HTTPS API
DNS is something network operators (and not just governments and ISPs) has managed and controlled in their own networks for decades.
It has been part of the network stack, with a clear hierarchy in how it is governed:
- network operator - network default
- operating system - application default
- end-user override - when the defaults doesn't work
When something has not worked, you could reliably assume this was the stack used. And you could rely on it being used consistently across all applications.
Needed to deploy internal applications? Great: Just override the (local, internal) DNS. Need to access servers or machines on internal servers? Use DNS!
Now if you make some random applications and decide to flat out ignore the established stack and just ask the internet about DNS...
You're effectively breaking the network and the conventions which has been established to build them.
Ofcourse people are going to hate you. That's a given.
> end-user override - when the defaults doesn't work
To my mind, the lack of privacy of classic DNS does indeed count as the the defaults failing to work. Yes, it would be more ideal to solve this at the OS level, but until OS vendors start providing solutions I don't begrudge applications that care about privacy for taking matters into their own hands.
1) Instead of proposing changes to the C resolver or a caching resolver the user might run they modified their application to ignore the operating system configuration which is just kind of crappy. Its probably the easiest and most reliable way to block things you don't like and now it doesn't work in firefox.
2) They are the singular (maybe there's one other now heh) resolver operator whereas with DNS anyone (even you) could (and did) run a recursive resolver.
3) I don't think anyone cares so much about this but http is probably the wrong protocol. The DNS protocol was pretty elegant in its efficiency and simplicity (IMO.) Yeah the compression was slightly complex (it's really not) but I've written clients without anything other than a socket library. HTTP on the other hand can do all kinds of complex things and has plenty of room for weirdness and tracking and unintuitive behavior that just isn't necessary for resolving names.
TL;DR: DoH is an unimaginative hack that has a lot of problems from a technical perspective but the social problems are much worse.
As for 1, if you're choosing to use a special resolver to do content filtering, you can disable DoH yourself. That's suboptimal but in my opinion it's better than not dealing with the broken DNS of the general public.
As for 2), it's not hard to run a DoH server yourself. In fact, it's much safer because it doesn't allow for amplification attacks like traditional DNS. The same goes for DNS over TLS (over TCP).
I agree with you on your third point though. I'd much rather have seen DNS over TLS being built into Firefox, especially as most DoH providers built into Firefox also provide DoT. DoT is easier to set up as well because you don't need any specific DNS server software (just have an nginx proxy the TCP connection to your existing DNS, it's about 10 lines of config).
I discovered that Android's "private DNS" functionality uses DoT. I feared they'd use DoH but luckily I was proven wrong.
I am not down on doh, I'm down on the possibility of Mozilla sending my DNS queries (ie my entire browsing history) to a company I haven't signed a contract with.
And I say the possibility because I'm not American so that's not enabled here (yet). But I trust my ISP and my government much more than I trust Cloudflare (zero) and I will be very disappointed (even more than I already am) at Mozilla if they enable it in the rest of the world.
Under unix in general (linux, bsd and, I assume, OSX) you can change your system resolver as you please. DoH is supported by several implementations to a various degree already. You can switch right now, for everything running on your system if you wanted to!
But browsers nowdays basically live under the following assumptions:
- the users are dumb, and "we know what's best for you" (well, to be fair this has been a consistent trend for everything in the industry)
- the OS cannot be trusted for anything, the baseline being the lowest common denominator of any old/broken version of android/osx/windows/linux they want to support
- the users cannot change the system resolver even if they wanted to because the OS is locked down (android, ios, and windows with group policies)
I think all the above reasons are detrimental, but at the same time they're all sadly true. Because browsers essentially are now not far from operating systems, they abstract themselves above everything, including the resolver.
Well, in the context of DNS resolvers and general computer security the vast majority users are dumb. Mozilla has does know what’s better for them. You, I, all of the readers of Hacker News - we’re the minority.
And for better or worse, the average user’s OS is hostile to a user’s privacy and security, with a few niche exceptions.
If operating systems had taken care of the problem already then Mozilla might not have to. I'm glad Mozilla isn't waiting around for them to protect my privacy.
Isn't this gonna cause a bunch of headaches though? What about people who connect to VPN and rely on the local DNS server to resolve non-public hosts? It'll work in everything but Firefox? Seems confusing.
What is the state of the art for Linux resolvers doing encrypted DNS? It looks like systemd's resolver isn't quite ready yet. I found a couple of other things on a quick Google; stubby and dnss.
Is there some simple thing I can apt install on my Ubuntu system?
That would be the best outcome, but until then Mozilla is making an effort to fill the gap until OSes supports DoH, DoT or DNScrypt out of the box and by default.
Since Mozilla makes a browser it was natural they'd try to solve it at the application level and not wait until M$ and other privacy loving OS vendors solve the problem.
> Why isn't this being solved on an operating system level
> instead?
It probably should be, but the undertaking is massive (cross platform) and browsers want a quick turn around. A lot of people would think that VPNs solve such issues, but it just pushes the problem further up the network.
In my opinion Linux would be a good candidate for such an initial implementation - but you wouldn't pick DoH, you would likely offer DNSCrypt or DoT.
Does the disable code still work in the about:config? I would rather not have the trusted providers see all our internal server names (which is wasted bandwidth and time) and our controls in the library work.
DNS resolution is the OS's job. This hijacking of function is a pain. Has no one at Mozilla ever had to deal with the realities of using their browser in an organization?
ESR is extended support and we use the regular Firefox. Firefox was never required by any vendor we use to remain compatible so we didn't have to be on the ESR branch.
I have some unusual, from the normal browser user perspective, DNS stuff and this just leads to a bunch of questions.
My gateway has a bunch of static DNS entries for internal hosts, which are all in a fake top-level domain. How will resolving these work if the request goes to CloudFlare? CloudFlare obviously doesn't know about my internal domain. Currently my gateway resolves what it knows about and uses my ISP's DNS to resolve what it doesn't.
Pi-Hole is presents a similar problem.
Finally, if DoH is the future, how do I run my own DoH server which can resolve internal hosts? Does such software even exist yet? How do I point Firefox at this DoH server? The relevant Wikipedia article[0] points to a list of public DoH servers I can use, but offers no insight as to what software I'd use to run one for my own use.
Your setup will still work. Firefox is configured with a "fallback" situation, where anything that doesn't resolve on the public resolver will be queried again using your system-configured DNS options.
As for Pi-hole, my recommendation is to block NATed traffic to Cloudflare's DoH traffic (forcing it into Fallback mode) and then setting up Pi-Hole to use for it's recursive resolution.
I’m gonna get some heat for this, but that’s OK; it’s my honest opinion.
I can’t really think of a better way to hamper progress on an open specification then by delegating the problem to some private corporation; especially one that has a penchant for censorship.
If more than .0003% of people actually used Firefox, we would have to worry about Cloudflare taking over the entire Internet. So it’s probably a good thing Mozilla ruined their brand over the past decade.
I would be willing to bet money that Mozilla is getting paid millions of dollars by Cloudflare for this.
In the meantime, this is the final straw for me. I’m done with Firefox for life. I haven’t used anything but Firefox since 2007... 13 years...
How does this work with hosts that are not resolvable outside your own network? If I tell firefox to go to internalsite.mycompany.com - which resolves internally, but not outside our network - how is firefox going to resolve it, if it's not using our DNS servers?
In order to preserve compatibility, Firefox's implementation has a "fallback" where if it sees that it can't resolve a domain, then it will fail back to using the system-configured DNS provider.
So now just one company will have access to all the data from 99% of firefox users? I don't see how giving so much power to just one entity is better for our privacy.
Previously if I used my computer at home, coffee shop, work, hotel etc it would be very hard if not impossible for one company to get all of my browsing history. And giving it all to one company is a better idea?
And many routers also cache local DNS requests. So unless someone can see every router that you were served by at every airport, hotel, coffeeshop, they really can't see where you've been browsing by examining DNS requests.
We're _much_ less safe having cloudflare know all.
Seems very marginal for privacy when people in the middle can still see the IP you're connecting to, just not which DNS record you may have retrieved the IP with.
Run wireshark on an ssl connection. The server certificate is sent in plaintext. It includes the DNS name of the server you connected to.
DoH would make sense in a world where that was fixed. (Though DNS over TLS is also a thing, and makes strictly more sense than DoH from what I can tell...)
It's actually quite massive. Most sites (well not most, but a lot) sit behind something like cloudflare, so your scummy intercepting ISP would only see a connection to cloudflare. Of course none of this really means too much until encrypted SNI is a thing but it's a definitely a lot more than marginal imo
Not all ISPs around the world have the resources to do that. It also doesn't have to be 100%, we just have to make it difficult (or more expensive) and that helps.
It's not complicated, but that's also going to take more time , cpu power, and memory bandwidth to do so than just recording dns packets. When you need to do that to millions or billions of connections per second the costs start to really add up.
It gets more difficult when you deal with aggregated traffic in the 10s or 100s of Gbps.
But yes, it is possible.
One thing is though - TLS1.3 is getting more popular and so is session resumption. So even now quite a bit of traffic cannot be identified and it will get harder and harder.
Encrypting DNS requests is one required piece of the puzzle.
It's far easier for ISPs to scrape up your DNS queries (they run the resolver) than it is for the to make correlations based on IP addresses, especially with multiple websites hosted on the same IP.
Until recently, I was working at CZ.NIC and people who are working on Knot DNS resolver were in the next office. The easiest way to get them crazy was to mention DNS over HTTPS. They hated it passionately.
I wish they wouldn't do this. I trust my ISP more than I trust Firefox and whatever company they chose for DNS over HTTP.
This "We know better than you" attitude is why I stopped using Firefox so many years ago. I switched back recently, to stop using Chromium, but I have a growing list of annoyances, and it might be time to give NeXt Browser a chance again, or see what else is out there.
"Firefox defaults to Cloudflare, though you can change this."
So it's whichever company you choose for DNS, rather than the company chosen by your ISP. Many of us were already choosing not to use the ISP's DNS, for reliability, but with this feature the ISP can't eavesdrop on that.
Most of us chose a company already, our ISP (or in my case a mixture of first + third party). Firefox are defaulting to their choice, no?
Presumably they give an option page on which to choose it - even they wouldn't be so egregious as to hide such a massive change without positive user consent, surely?
Well, honestly, I don't use my ISP's DNS, either, but that just highlights another way this is annoying: Firefox is overriding my decision with their own.
And like I said, I trust my ISP more than I trust Firefox and CloudFlare, so their spying on my DNS (if they even are) is less of a concern to me than CloudFlare or Firefox spying on the requests.
While I may or may not trust cloudflare more than my isp, the fact is that my isp has my billing information and address on file. I do not pay anything or provide any personal information to cloudflare. So to me, there is an advantage to not having all my eggs in one basket. While I'm sure cloudflare could tie your DNS lookups to your identity, it would be much less trivial for them than your isp.
Agreed, I dislike the paternalism and wish competition in the browser space was much more robust. I'm Google averse and hooked on Tree Style Tabs so Firefox it is for the time being
DNSSEC does nothing to provide DNS privacy, nor does it address MITM attacks between endpoints (your phone and laptop) and DNS servers; it's a server-to-server protocol. DNSSEC is moribund; practically no important sites run it.
DNSCurve/DNSCrypt are directly competitive with DoH, but in a post-DoH world, both are probably dead-letter standards.
I predict that DoH will break many enterprise infrastructures that rely on custom DNS servers. Unwary sysadmins that update Firefox will be in a lot of trouble when they switch this on by default.
We ourselves have a custom DNS setup with an only internally resolvable TLD as a security measure, so this change will break our infra for all Firefox users (thankfully we’re in the EU so we’re spared, for now).
Good thing that Cloudflare wants to centralize DNS and access control anyway, so those enterprises can just switch to their proprietary DNS service and VPN replacement, I guess ;)
Firefox by default is configured with a fallback option, where if resolution would fail, it will fallback to the system-provided DNS servers. So your internal TLDs are safe.
Additionally, if you've setup Firefox to be installed with Firefox for Enterprise, DoH is disabled by default and you've got nothing to worry about. DOH is able to be configured through GPO as well, allowing the use of a custom server.
And that is even more dangerous, it would mean that if for some reason an identical domain extists on the internet (or somebody registers it to do an attack) then all the hosts will connect to the malicious external domain and not the correct host in the internal network. Local hosts should be resolved FIRST.
Also cloudfare this way gets the DNS names of your internal hosts, you are leaking information that otherwise would be private, and system administrator will probably not think about that!
Also with that option is not really secure at all, if somebody wants to intercept your DNS requests he can simply block the IPs of Cloudfare DNS over HTTPS server and then read the DNS requests unencrypted.
In all reality, your Enterprise should own the domain externally. What happens if one day a configuration flag is flipped and you're no longer resolving internally the domain?
If you have a problem with Cloudflare, go setup your own, it's just BIND9 with some SSL certs.
Well, ok, but this requires updating all company DNS servers so it’s still far from ideal I would say. They should have done it the other way around: if the DNS returns a specific response enable DoH, otherwise leave it alone.
I recently upgraded my home router to DNS over HTTP (pfSense now supports it pretty easily).
I started with Quad9 (9.9.9.9) and Cloudflare as a backup (1.1.1.1).
One thing I noticed right away was that my ping times to Cloudflare ended up being way faster (15ms) compared to Quad9 (50ms). Cloudflare seems to have a presence in my local area.
Now both are good, but adding a 50ms delay (+TCP handshake + TLS setup and teardown) seemed like a non-trivial amount. I ended up putting Cloudflare first.
There was a noticeable difference, something to think about if you decide to set this up.
> Cloudflare seems to have a presence in my local area.
In case you're interested in rolling out your own low-latency DoH: I run a DoH stub-resolver on Cloudflare Workers [0]. Their free-tier covers one device's worth traffic. You could do so on stackpath, too [1].
Can someone please explain why there can’t be a DHCP or RA option for which DoH server to use? Why are we going out of our way to make sure the sysadmin has to configure each and every piece of software on each and every single PC rather than just set it one in a centralized location, like every other networking option?
DoH will leave my machines unable to resolve all my internal domain names, right?
