Mozilla’s DNS over HTTPs
blog.mozilla.org
blog.mozilla.org
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.
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.
Ref: https://wiki.mozilla.org/Trusted_Recursive_Resolver#network....
You have leaking internal hostnames there.
To be fair, it is difficult to make all parties satisfied there. I think that a bit more honesty during discussion would help.
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.)
Why?
Well, this explains why Archive.is never works...
So basically whether Mozilla is doing the right thing or not here is entirely dependent on who the archive.is operators decide to target?
What about all the services that will be fixed for users after Mozilla makes this change, due to poorly operated DNS from the provider?
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?
Yes, are explaining to our colleagues what IP address, subnet, route, or interface are.
--Someone with a decent understanding of networking
> 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.
Breaking DNS is madness IMHO. Its just more sites that dont work on FF.
Broken is not more secure, its just broken.
Apart from the wait.
Spaff hostnames to cloudflare, fail, then try harder.
Users expect
hosts: files,dns
Admins expect dns to work.
FireFox should not be fscking with network config.
If they do, they should try not to break users first.
Firefox is borken. Security is not improved. My DNS requests never leave the LAN.
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.
So in other words: privilege escalation.
These are separate features and should be decoupled accordingly.
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.]
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 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.
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?
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.
For free software, squid ssl-bump works, though is something of a pain to configure!
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.
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.
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.
What the hell am I supposed to do again cloudflare?
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.
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 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.
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.
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.
Also consider that privacy is not an exclusive goal for mozilla: https://www.mozilla.org/en-US/about/manifesto/details/#princ...
Principles 2, 5 and 6 would be endangered by a single global actor (no matter how benevolent) being in control of your software.
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 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
This covers a very large fraction of the most downloaded extensions https://addons.mozilla.org/en-US/firefox/search/?platform=wi...
> 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.
[1] https://support.mozilla.org/en-US/kb/permission-request-mess...
"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.
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
It's extremely hard to keep track of and manage "opt outs", especially in a household with multiple computers and multiple people.
Formerly, I "opted out" of having a browser that phoned home my browsing traffic by using Firefox.
Formerly your browser still "phoned home" to your default DNS provider, using an insecure protocol.
I appreciate your concerns but, unless you run your own DNS server, you have to trust someone at some point.
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.
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.
We should endeavor to build something good enough today, so someone in the future can build something better on our shoulders.
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 not taking sides here but the argument was made, and valid.
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)
[0]: https://developers.google.com/speed/public-dns/docs/dns-over...
fwiw I agree with you about a central body getting all out DNS requests.
> DHCP will give you a DNS config
So in other words "your default dns provider"
> that DNS server can be local, remote
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.
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.
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.
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).
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?)
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.
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.
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.
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?
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).
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!
[1] https://developers.cloudflare.com/1.1.1.1/fun-stuff/dns-over...
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
* 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.
For example, because it’s not using HTTP, there are no cookies or SNI to worry about.
> For example, because it’s not using HTTP, there are no cookies or SNI to worry about.
> More at https://news.ycombinator.com/item?id=22418005.
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.
[1]: https://www.ctrl.blog/entry/unbound-tls-forwarding.html
[2]: https://labs.ripe.net/Members/bert_hubert/centralised-doh-is...
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.
[1]: https://labs.ripe.net/Members/bert_hubert/the-big-dns-privac...
[2]: https://www.ietf.org/archive/id/draft-dickinson-doh-dohpe-00...
and you believe CloudFlare is not a "evil state actor" or has not been compromised or never will be compromised by an "evil state actor"
Wow your faith in CloudFlare is much much higher than mine
Personally I trust my current ISP (which is not one of the big boys) more than I trust CloudFlare.
I do not trust cloudflare at all and believe they are the are one of the biggest threats to the future of open web there is today.
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.
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.
For now. Where's my option to disable complete blocks on domains with funky/invalid SSL certificates? Gone, for the past few years.
Sure, most people don't need that. Most people don't care about DoH being enabled by default, either. I do.
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.
I wonder how much Cloudflare paid for this 'privilege' of being the default DNS provider.
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.
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.
> DoH seems like a huge step forward in ensuring that no unencrypted traffic is visible to the ISP or local network
It does not do this.
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.
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.
Not in my country, they'll be massively fined if they're caught doing that.
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 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.
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.
It might make it harder to block queries by deep packet inspection, but do you actually do that on your network right now?
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.
The number of such servers is in the several thousands, at least. They also move and new ones spin up, requiring constant updating of the blacklist.
It's much more effective to take a whitelist approach or, what I do, just block the DNS lookups for them all.
(That said, I do keep such a blacklist, as one small part of my multilayered security approach.)
The next level up is to block the DNS lookups that happen when the spies are trying to find their servers. That's what DoH prevents.
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.
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.
That was already true though, because they could have used those mainstream providers' unencrypted DNS servers too.
> Sure it is. It effectively disables a layer of defenses from the spies.
But why would any spy rely on such a layer when you've left the front door (unencrypted DNS) wide open?
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.
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.
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.
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.
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.
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.
Uh. Doesn't this prove that Firefox's DOH implementation is sending strong per-user identifying information to the server?
If you’re hitting cloudflare, it’s just hitting the regular endpoint so no user identifying information.
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.
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.
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.
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 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.
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.
Have you considered using a different browser? One that aligns more with your values?
For the majority of users who may not understand the risks around plain text DNS, there are advantages to it being encrypted.
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
DoH should be Opt-In, not Opt-Out
Technical users (like yourself) can just easily disable DoH, problem, for you, solved :)
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.
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.
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.
$ whois 208.80.153.224
NetRange: 208.80.152.0 - 208.80.155.255
CIDR: 208.80.152.0/22
NetName: WIKIMEDIA
NetHandle: NET-208-80-152-0-1
Parent: NET208 (NET-208-0-0-0-0)
NetType: Direct Assignment
OriginAS: AS14907
Organization: Wikimedia Foundation Inc. (WIKIM)
RegDate: 2007-07-23
Updated: 2014-01-29
Comment: http://www.wikimediafoundation.org
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
minjiexin.com resolves to the same IP. So, you see an HTTPS connection to 208.80.153.224, what's the user doing?
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.
$ telnet minjiexin.com 80
Trying 208.80.153.224...
Connected to minjiexin.com.
Escape character is '^]'.
GET / HTTP/1.0
HTTP/1.1 400
[...]
<!DOCTYPE html>
<html lang="en">
<meta charset="utf-8">
<title>Wikimedia Error</title>
[...]
Big mystery.
https://old.reddit.com/r/pfBlockerNG/comments/d3p1gf/doh_ser...
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.
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.
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.
https://corporate.comcast.com/stories/privacy-with-comcasts-...
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.
[0] https://developers.cloudflare.com/1.1.1.1/commitment-to-priv... [1] https://arstechnica.com/tech-policy/2009/08/comcasts-dns-red... [2] https://www.theacsi.org/news-and-resources/press-releases/pr... [3] https://consumerist.com/2014/04/08/congratulations-to-comcas... [4] https://www.atg.wa.gov/news/news-releases/ag-announces-lawsu...
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.
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.
That is not how arguments work.
> But just because they could break the agreement does not mean we should jump to any conclusion that they are currently.
Oh, and straw-maning, too? Brilliant!
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?
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".
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.
I'm just going to tell my mother in her 60s about editing about:conf settings.
This shouldn't be opt-out.
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.
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!
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.
Using English is the path of least resistance
Firefox is used outside of the EU. Speaking of which...
> I am always using the US-EN Firefox version
Wait, so you want the US version of Firefox to be tuned to EU legal policy?
> Wait, so you want the US version of Firefox to be tuned to EU legal policy?
It is not the US version. It's the US language version - or at least that's how they market it.
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.
And if you use VPN, they can see your traffic.
Personally I trust my ISP more than some random VPN provider on the net.
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).
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.
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.
Can you please edit swipes like that out of your comments when posting to HN? They break the site guidelines and provoke others into doing worse.
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.
These things are matters of degree in any case, and "what are you even talking about" is clear cut.
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.
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
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.
> 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.
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.
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.
By only responding to one person it gives the impression that you think the first person did nothing wrong.
That said, I will avoid that specific phrase on this site as you asked.
Some phrases come with a built-in sentiment that people will assume exists unless it's overridden.
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.
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.
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)
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.
At best even it were currently use it only provides protection for sites which are hosted behind DOS mitigation services. (usually cloudflare...)
https://encryptedsni.com/ -> https://www.cloudflare.com/ssl/encrypted-sni/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.
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.
Keep in mind, it's not just what you visit but how often as well and a lot other details (dns is cached)
TLS+SNI sends the `Host` you are connecting to in plain text. eSNI is not yet widely deployed.
Centralizing DNS without centralizing HTTP (e.g. domain fronting) does not solve the leak of connection metadata.
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.)
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.
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.
> 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.
People _are_ using a different browser.
People _have_ forked, (mostly webkit based)
When everyone has stopped using FireFox, will Mozilla conclude that the Internet is finally secure?
If we see an uptick in Firefox usage we can presume Mozilla's value judgement was correct.
Encrypted SNI and OCSP stapling solve those problems.
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.
it removes many parties (some unknown) who have no legal oversight, and adds a select parties who are legally bound to respect your privacy.
> because the user's destination IPs remain unencrypted
This makes no sense. your ISP cannot see that you are visiting facebook because the IP shows up us cloudflare urrrghhh!
> At the moment you can disable this across your whole lan
now that is a "massive attack on user privacy"
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.
OK. Perhaps you have some examples in mind?
> 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).
There are many massive databases of ip to hostname mappings which can be trivially queried by an ISP to see what service you're connecting to.
Or if they see you connecting to 185.60.216.35, they can just:
curl http://185.60.216.35 -v 2>&1|grep Location
openssl s_client -connect 185.60.216.35:443 2>&1 | openssl x509 -text|grep Subject:
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.
Fuck that.
What can I, citizen of small EU country, with an en_US firefox, do against cloudflare?
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!
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.
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.
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.
I do care if they know I visit reddit.com/r/something
I'm already protected by TLS for the latter. Newer TLS will eventually protect me from the former (in combination with DNS encryption).
True
> 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?
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.
Optional for menu icon:
https://getbitbar.com/ and https://github.com/jedisct1/bitbar-dnscrypt-proxy-switcher
The .org is not legit.
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).
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.
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.
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).
Tell that to China, Iran, Turkey (?), etc.
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.
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.
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).
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
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.
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.
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.
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???
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.
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...
What's a "trustworthy" device in this circumstance? If you can never verify then it's not trust it's faith and hope.
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.
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.
Anything that uses our recursive servers is monitored, and we can check against blacklists, either in real-time or after-the-fact through logging.
* https://en.wikipedia.org/wiki/Domain_generation_algorithm
* https://en.wikipedia.org/wiki/Botnet#Domains
If malware is connecting to hard-coded IPs then there's nothing we can do about that.
So yes: monitoring DNS for suspicious activity is part of our security strategy.
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.
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.
DoH has reduced visibility into my own network.
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
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.
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/).
> 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.
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.
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?).
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.
It gives them a competitive advantage in DNS industry against other B2B providers, such as NS1.
Surely the only way that's possible is if they derive data about users, which they can then sell .. which is what Mozilla claim to be preventing.
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.
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.
We've seen the "don't be evil" free stuff thing turn sideways before.
> We intend to publicly document violations of this Policy and take additional actions if necessary.
I believe that those "additional actions" will prevent providers from violating the policy. If not, they will be removed from Firefox.
Other countries have censorship (China, UK, New Zealand, etc) whereas there is none in the US.
I wonder if that’s why?
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.
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.
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.
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.
I think you have some reading to do.
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.
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.
How many people do you know that running local resolvers? How would this even work on Windows?
The world doesn’t need another encrypted dns solution that only works on Linux
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.
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.
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.
Just use a DNSSEC capable resolver in combination with a VPN. All other options today are effectively theater.
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.
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.
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.
To be honest my main gripe is with DoH. For non-last-mile privacy/trust, there are indeed many suitable ways to tackle it.
Explain that to me?
There are 40 publicly available servers listed on https://github.com/curl/curl/wiki/DNS-over-HTTPS from large and small players.
https://support.mozilla.org/en-US/kb/canary-domain-use-appli...
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.
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.
[1] https://github.com/mozilla/policy-templates/blob/master/READ...
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.
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.
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.
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?
You can attempt to block and filter things, but there will always be a way for something malicious to bypass it.
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.
You're kidding, right.
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.
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.
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.
It is 100% not the place of an application to meddle with network services, particularly not by default.
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.
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.
FWIW, my entire peergroup grew up without anyone installing content filters on their computers, and porn was already widely available back then.
What use cases do people have in mind?
* State censorship. Totalitarian.
* "Parental controls". Child abuse. Learn how to build trust in your children instead.
* Corporate filtering. Find other ways to motivate your employees than blocking Facebook.
The problem with this implementation is that it doesn't go far enough. I want software to actively fight against the idea of content filtering.
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.
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.
Curious if the issue lies with us or Mozilla.
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.
The ISPs need to support DoT server-side, at their end?
That's not how DNS works.
Just put DoT capable cachine-resolvers onto each host, and you're golden. Those to even play nicely with enterprise infrastructure, like a local DNS.
I'd guess that 99+% of Internet users have no idea how to run their own DNS server, let alone set up DoT.
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.
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.
I did write, that DISTRIBUTIONS should set this up by default, not the users.
And Microsoft could do the same for Windows, as could Apple (with almost zero effort) for MacOS-X
Not seeing _distributions_ there
>> Because that's something that OS vendors could easily and trivially deploy with only minimal effort.
"OS vendors" aka "distribution creators"
And then in the 3rd paragraph, I wrote (sic!):
>> Just put that as out-of-the-box setup into default Linux distributions' installation:
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.
Take a look at the article DNS Wars; it’s eye opening: https://blog.apnic.net/2019/11/04/dns-wars/
How is that different than existing DNS servers?
Because standard DNS servers using mostly UDP can’t track you the way a DoH server can.
The more centralized DoH becomes, the more tempting it’ll be to monetize that traffic.
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.
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.
There is a 3rd option: Operating your own recursive resolver.
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.
DNS is the primary way governments control and spy on web access.
DNS is the most openly insecure aspect of the entire internet. It’s wide open.
2) to implement this canary, you have to break DNSSEC on entire .net root domain. Great.
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.
There are a few dozens of DoH services out there [1] and nothing prevents anybody else from running their own.
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.
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.
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.
Why don't they ask DHCP for a nice stratum 1 server instead, I don't know, maybe someone here does?
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.
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.
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.
The job blocking domains should be the job of a firewall. Of course this becomes more complex. But any application can implement DNS over HTTPS.
Malware could even just get a list of IPs from another IP.
An application can even just hard code IPs rather than using DNS and then they're in the same position.
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.
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.
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.
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.
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.
They can block the canary domain[1].
> Of course their argument was parental controls being made ineffective.
DoH is disabled on Windows and macOS if parental controls are enabled[1].
[1] https://support.mozilla.org/en-US/kb/configuring-networks-di...
And second, as an IT admin, I’m annoyed web browsers keep trying to develop new ways to bypass my network security.
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.
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 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.
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.
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)
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.
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?
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)
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.
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
Also, turns out that malware has already jumped on the DoH bandwagon.
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.
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.
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.
Under about:config, it seems like network.trr.mode with values 2 or 3 are good choices, https://wiki.mozilla.org/Trusted_Recursive_Resolver#network....
UPDATE: network.trr.mode with 3 is not working for me in Australia.
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.
> 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.
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.
And for better or worse, the average user’s OS is hostile to a user’s privacy and security, with a few niche exceptions.
Is there some simple thing I can apt install on my Ubuntu system?
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?
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.
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.
Alternatively, you can setup your own DoH server based off BIND: https://terminaladdict.com/networking/linux/2019/09/13/DoH.h...
The easiest stub resolver to setup would be nextdns' client: https://github.com/nextdns/nextdns
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...
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.
https://support.mozilla.org/en-US/kb/firefox-dns-over-https#...
It looks like Firefox Policies can be used to enable, disable, or specify the DoH provider but cannot yet specify excluded domains.
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?
We're _much_ less safe having cloudflare know all.
tcpdump -i any -s 1500 '(tcp[((tcp[12:1] & 0xf0) >> 2)+5:1] = 0x01) and (tcp[((tcp[12:1] & 0xf0) >> 2):1] = 0x16)' -nnXSs0 -ttt
0x0110: c008 0016 0013 0010 000d c00d c003 000a ................
0x0120: 00ff 0100 0113 0000 001d 001b 0000 186c ...............l
0x0130: 6f67 7369 6e6b 2e64 6576 6963 6573 2e6e ogsink.devices.n
0x0140: 6573 742e 636f 6d00 0b00 0403 0001 0200 est.com.........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.
So hopefully not a cause that's lost forever, but we can improve more in the future.
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...)
Not with TLS 1.3, which moves the server certificate to the encrypted part of the handshake.
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.
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.
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?
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.
DNSCurve/DNSCrypt are directly competitive with DoH, but in a post-DoH world, both are probably dead-letter standards.
[1] https://www.digitale-gesellschaft.ch/2019/04/11/oeffentliche...
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 ;)
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.
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.
If you have a problem with Cloudflare, go setup your own, it's just BIND9 with some SSL certs.
Not because something is not routable means that there won’t be issues.
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.
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].
DoH will leave my machines unable to resolve all my internal domain names, right?
There is. You configure your DNS resolve this "canary" domain to disable it.
At the moment, Mozilla wants to push this for users where DoH just works, for people it doesn't providing options to disable it.
Once resolv_doh.conf becomes a thing for all platforms (Linux, OSX and Windows) they can use that.
Perhaps some thought as to service discovery should have been done:
* https://tools.ietf.org/html/rfc6763
If Mozilla is going to re-invent the wheel (OSes already do DNS look ups), they perhaps should have asked the DNS folks (e.g., DNS-OARC) about some of the corner/use cases IMHO.
Some DNS hosters disallow private IPs. Some public resolvers and consumer routers will filter out responses containing private IPs.
We're in this mess because OSes haven't acted and Mozilla has had to take matters into their own hands. Unfortunately any solution that requires cooperation from other software is going to take a lot longer to land.
I do hope it happens eventually, and I'm sure that when it does Mozilla will change Firefox again to respect that.
There's also the fact that there's no DHCP option reserved for DoH/DoT/DNScrypt (yet) which requires some standardisation work.
There's various APIs to read the current DHCP configuration for a network interface so technically it shouldn't be too hard (at least not when it comes to Windows or macOS where there's standard APIs, as opposed to Linux whose modular layout makes finding a standard location for DHCP config difficult).
If they do not, they should be marked as forwarders for their respective domains. Something like `Add-DnsClientNrptRule -Namespace "domain.com" -NameServers "1.2.3.4"`
The operating system will have this information; an application, like browser, won't.
Seriously, do you disagree that it leaks information? Do you agree that it does, but believe it is less problematic for two companies to have this information than having it sharded across all ISPs? Do you agree that it's more problematic but you don't care for some other reason? Do you agree that it's problematic and care but don't like how I express my point? Do you agree, care and like my expression but think it adds no value to HN?
I can't learn if we don't discuss the issue.
(I agree with what you've said here, FYI)
There is no need to configure individual applications and no need to develop a new means of distributing DoH server information.
The Same thing OCSP Stapling (Online Certificate Status Protocol) extension which also sends the hostname.
Cloudflare crafted a solution for this by storing the public key of the target website along with the DNS record. So during DoH when the user asks for IP of a given host, it can also get the public key of the host. User then establishes the TCP, encrypt the SNI extension & OCSP with the public key and starts the TLS handshake.
Though ESNI doesn't seem to provide perfect forward secrecy it is a leap forward.
In every DoH/DoT discussion there is someone who mentions ESNI, but without major level support this is a vague promise. Of course DNS encryption is still useful even without ESNI.
https://twitter.com/NP_tokumei/status/1220802795512578048?s=...
Do they establish a connection and leave it open for a long period? Supporting that would be a big commitment on the part of the resolvers.
HTTPS/2 over TLS 1.3 (which is the baseline you should assume for these relatively new services) is one TCP setup plus potentially 0-RTT TLS on all but the first visit.
0-RTT is safe here because a DNS query is just a question with no side effects. Replay attacks (the risk 0-RTT incurs) don't do anything:
Gumby: "What is the IPv4 address of news.ycombinator.com?" encrypted so that only DoH Server and you can read it
Server: "209.216.230.240" encrypted so that only Gumby and the DoH server can read it
Attacker: Replays Gumby's packet with no knowledge what it means
Server: Same reply, also unintelligible to attacker just like the original
For HTTPS/3 (over QUIC rather than TLS+TCP) it's UDP so the only "overhead" is from the crypto setup which is modest on even a relatively weak machine.
The current system using a cache works relatively well until you want privacy.
Can some security minded folks from the community chime in about the claims made in the linked article?
(Disclaimer: English is my second language)
[1]: https://www.zdnet.com/article/dns-over-https-causes-more-pro...
For example, it points out that DoH doesn't really protect privacy from ISPs because ISPs can still see what the users are doing because the ISPs route the traffic. Then, it claims that DoH weakens security because it would let users get around malware blacklists. However, this is mostly nonsense for the same reason. Malware (and other legitimate blacklisting) can and should be blocked even when hard-coded IP addresses are used.
The point about the logistics is very true, though. I won't use DoH at home because I operate my own DNS that contains intranet addresses not accessible from the outside Internet. DoH in Firefox would break those services.
I hope it's just a matter of time before they fix this :)
DoT is better because at least it's obvious if your ISP/Gov is blocking port 853 (at which point you install a VPN or run your own resolver somewhere and tunnel to it or swap provider or move country). Meanwhile you get all the usual benefits of decentralised DNS resolution and don't have to worry about the unforeseen overhead and bullshit DoH is going to spwan.
Firefox is an app for browsing websites. What business does it have pushing a half baked compromise solution that undermines core infrastructure, creates a false sense of privacy and introduces second order effects that will result in DNS lookups being centralised in to the hands of a few giant US corporations (at least changing to 1.1.1.1 or 8.8.8.8 was opt-in).
Also can't wait for the inevitable instances of Cloudflare deciding not to resolve certain domains (effectively becoming the de-facto arbitrator of what most FF users can and cannot see on-line). For a preview of that, try going to archive.is with 1.1.1.1 as your resolver.
Ultimately, all of this is moot anyway (even once ESNI arrives). Regardless of DNS, your device still needs to connect to an IP. Entities interested in where you are going will still be able to get reasonable insight by simply correlating IP addresses and CT logs (http://blog.seanmcelroy.com/2019/01/05/ocsp-web-activity-is-...). The only decent solution to this, and available right now, is a VPN (at which point DNS privacy is automatically solved for you).
If Paul Vixie thinks DoH is a bad idea then... it's a bad fucking idea: https://twitter.com/paulvixie/status/1053765281917661184
The more I think about it the more I realise Microsoft's and AOL's instincts were right. Make the internet a walled garden and insert yourself as the gatekeeper.
Their mistake was to do this too early. ~25 years later and the people are now finally ready and willing to allow billion dollar coporates to overtly "manage" their on-line experience for them. Companies love this too because it removes yet one more unseemly shackle from their ambition (i.e. that of needing to work collaboratively with potential competitors) while at the same time providing them with a nice vector to defend their quasi monopoly.
All of the bad actors from the users’ perspective (ads, tracking, etc.) will sit behind Cloudflare, Cloudfront, etc. and you won’t be able to do anything about it.
So, if this rolls out 'as-is' in any other country than the US, we will go from "all DNS requests are clear text, but dispatched among many entities" to "DNS requests are encrypted, but all read and controlled by american agencies".
We (may) have gain (some) privacy (maybe). But we also (certainly) gained a serious dependency.
When they roll out in the EU, I will pay close attention to how they are doing it, what partners they use under what jurisdictions etc.
Gotta also make sure I don't get a US Firefox build somehow.
But good point, now I am curious how they detect US-ness. Probably a combination of using the en-US and some geo lookup?
But to make things more honest, I'll edit my comment.
Given the way my country went from freedom to "regime de Vichy" in a few years, during my grandpa time, I don't want a state level entity having that kind of power.
Since the US state level entities decided they could now ignore Habeas Corpus and legitimated torture, secret courts and declared impunity for them-self, I especially don't want them to have that kind of power.
This let them control how people think, communicate, consume and inform them-self. But also detects anyone that could oppose the regime. Or make a graph of all allies, suspects, etc.
Then you hit them with a rubber hose :)
Example #1: I have a personal server running at home that is reachable from the internet through a PageKite tunnel. It's reachable through a public address of the form https://xyz.pagekite.me. The connection is secured by a Let's Encrypt certificate, which means I have to use this address to avoid HTTPS errors and the domain has to be reachable from the internet so I can fulfill challenges.
However, I'd also like to access the server from my LAN without an unnecessary round-trip through the internet: I might want to avoid unnecessary data costs or display certain content only available to LAN clients. So from the internet, the domain should resolve to the PageKite tunnel, but inside the LAN, the domain should resolve directly to the server's LAN address.
This is relatively easy to accomplish using traditional DNS: Just set up a local DNS server that serves the LAN address. However, how do you do that with DoH?
Example #2: You want to set up an internet router at home. The instructions ask you to connect to www.routerlogin.net to pull up the web interface. The domain is split-horizon: When requested through the router, it will resolve to the router's internal address and be served by the router's internal web server. When requested from the internet, it will point to a generic info page from the vendor.
Now with DoH, you'd always see the generic info page, even when connecting through the router.
>Q. Will DoH lead to a greater centralization of DNS, which will be bad for the Internet as a whole?
>A. We agree that centralization is bad for the Internet. Today in practice, DNS is >centralized because consumer devices are locked to the DNS service of the ISPs. >And just five companies control over 80% of the US broadband internet market.
For one thing, 5 independent providers within the same country is not exactly centralized in my opinion. As far as I understand it Americans don't always effectively have the choice of which ISP they can use, but that's not a technological problem. You won't solve monopolistic and anti-competitive practices with a new layer 7 protocol.
Furthermore what does Mozilla mean by "locked to the DNS service of the ISPs", do they block DNS queries to other services? Here in Europe I can switch to a different DNS any time I want. Sure, it's easier to stick with the defaults and most people will do that but "locked" is a strong word which I suspect is inaccurate in this case.
By that definition of "centralized" you could argue that email is effectively centralized since most people just use the free service provided by a handful of providers.
>The immediate impact of Mozilla enabling DoH in Firefox will be less >centralization, not more because it shifts traffic away from large ISPs, and >provides users with more choice, while respecting enterprise DNS >configurations.
So 5 ISPs meant that the service was effectively centralized, but (at this time) two competing DoH services with Cloudflare selected by default is "less centralization"?
Some providers use MitM attacks on DNS queries, to do things like block content or replace NXDOMAIN with SPAM. (Probably obviously, this is not possible with DoH.)
It must be nice living in a place where you don't have to worry about access. But for many of us, there's no point in privacy without access.
Firefox won't bother checking the canary domain if the user clicked "OK" to the DNS-over-HTTPS question.
Are they surprised that a change made in the name of preventing your local network operator from slurping your DNS information doesn’t create a way for local network operators to just ignore DoH and slurp DNS information?
To needlessly ramble on a bit: A simple header or html tag could "ok" all or specific alternative ways of distributing and provide conditions. Say, if my blog is unavailable for > 3 months you can p2p distribute it by [for example] fast, medium or supper slow means. Currently I look at articles I wrote long ago. I've carefully selected 10-30 links of which 20% still work(!?) I've picked them specifically because they are probably unfamiliar to those interested in the topic.
They can claim all they want it's not logged or anonymized but that's like believing the same claims by your VPN service, you have no idea if they are operating under a silent security order from some agency.
And unless I am missing something, unless you are tunneling though VPN, proxy, etc. your ISP is well aware of every IP connection you do, they simply just rDNS if they want to know.
I understand how DNS, HTTP, and most of HTTPS work at the wire level (a little fuzzy on how the decisions are made, though). It’s just using a different transport strategy to acquire an IP address from a FQDN. Every step of that process has a logic to it, and none are mutually incompatible.
And yet... my brain keeps alerting, asking what kind of madman does the HTTP before the DNS. Maybe it’s the “to make an HTTP connection, first you must make an HTTP connection” part that gets me. I can’t say. But it just feels wrong, despite being more sustainable.
I don't have a Facebook account but with Firefox TRR, 'google.com' is the only address that resolves just fine — so I search Google (or directly from the address bar) for a website, click through to the result, and the ensuing session is allowed. Rinse and repeat for each new tab.
Any direct attempt to browse otherwise (including to google.com with other browsers) always hits the FB captive portal.
> 100% of your ad spend is placed for active users that opt-in to a rewarding private ad experience.
> Craft effective offers and provide captivating full-page experiences directly with consumers in Brave’s Private Ad Tabs.
> Brave uses local machine learning with the browser profile to only place ads in optimal conditions. Ads are matched to opportunities, and users become partners instead of targets.
> Private ad matching efficiently matches ads directly from the device, without breaching personal information.
The same thing you saw happen to any other cryptocurrency. It basically kills all earnest conversation.
The Brave thought this was worthwhile makes the whole thing feel scummy to me. But we are way off topic.
I know "Have I Been Pwned" is supposed to be a security tool for white hats, but the fact that they collected hundreds of millions of users passwords seems at odds with that.
Additionally, there's a service called 1password that leverages this data. It claims to be a tool to help users know if their password has been compromised. But a service that has the ability to check a user's current password against a database seems at odds with that.
On a completely unrelated note-- do you know how Brave actually implements advertising in their browser?
I mean, this is ridiculous: https://ffp4g1ylyit3jdyti1hqcvtb-wpengine.netdna-ssl.com/net...
> System administrators can find relevant documentation here.
I'm pretty sure "here" should be a link, but of course that doesn't work when the marketing department uses a PNG instead of HTML.
I'm also surprised that Mozilla / the CDN don't optimize the PNG. `zopflipng` reduces the size from 285K to 153K.
And of course it's named "Final-DNS-over-HTTPS-05-1.png".
They could've used an image map. /s
Guess I will disable it.
How does Firefox deal with corporate installations and internal DNS?
Everything is configurable and there are canaries to override that.
But how many people are going to change it from the default?
https://blog.mozilla.org/netpolicy/2020/02/25/the-facts-mozi...
The only reason I can think of (or I can understand) is regulation and laws, but it doesn't seem to be the case.
As one of my favorite people told me once: words mean things. The words we use matter, as humans do not have telepathy.
Guess I'm not using FireFox any more. :(
A naïve protocol capsuled inside a stupid and dangerous protocol.
I do want a container with my own DNS-over-HTTP running on my own hosted VM (or Digital Ocean, or Vultr or Linode or whoever) and I'll ship my DNS queries there.
You might also be interested in looking at https://dnsdist.org/guides/dns-over-https.html
In my home setup I'm already using DNS over TLS to talk to the internet, but on the LAN requests go to my DNS server, get cached there, etc.
I'm in the "this should be done by the system resolver" camp, and I hope they figure out how to push that for all the major platforms ...
There are numerous other options like Google, Quad9, OpenDNS, OpenNIC, DNSWatch or Verisign, each of which have pros and cons like speed, privacy, reliability or accuracy. Many people also use VPNs which provide DNS servers that are perceived to increase privacy.
I know this is currently US only but were it to roll out worldwide, personally I'm in a country with strong legal privacy protections and trust my ISP far more than any American company.
To be honest I don't use Firefox that much compared to Chrome.
Because if 90% of websites are hosted on unshared IPs, then this whole thing about DoH and/or ESNI providing some sort of privacy is complete bunk. An ISP can still see exactly what website you're visiting when connecting to an unshared IP by virtue of which IP you're connecting to. The methods for mapping a raw IP to a website when that IP is unshared, are numerous and effective.
DoH/ESNI only provide privacy if the vast majority of websites are on shared IPs.
DoH/ESNI only provides privacy if we have already (or are planning to) centralise web traffic behind a handful of gatekeepers.
I guess that's step 2 in "advancing" the web.