Hacker News new | past | comments | ask | show | jobs | submit login
Mozilla’s DNS over HTTPs (blog.mozilla.org)
648 points by Vinnl 44 days ago | hide | past | web | favorite | 757 comments



As a resident of a country whose government and ISPs heavily and habitually censor the Internet for political reasons, I for one truly appreciate Firefox's DoH. They should also enable 'network.security.esni.enabled' by default because the censors here have upgraded from DNS to SNI-based blocking. I get it that better solutions are possible, but got to teach people to first walk before teaching them to run. AFAIK, Chrome still doesn't support this kind of simple user-friendly privacy options for the average non-technical user.


Chrome uses opportunistic DoT - it uses your system configured resolver, and if it supports DoT, it will use DoT, if not, it will fall back to 53/udp.

I like Chrome's approach much better; it doesn't force you to statically configure DNS server - it is a PITA, especially when roamining and you want to resolve hostnames available only in local networks.


> ...it is a PITA, especially when roamining and you want to resolve hostnames available only in local networks.

Not really.

If you're not blackholing traffic at the dns-layer via DoH, set Firefox's trr.mode to 2. Per documentation, at the cost of additional latency incurred, system-level / network-level resolvers should pick up the slack, provided they've been set as appropriate via DHCP or otherwise.

Ref: https://wiki.mozilla.org/Trusted_Recursive_Resolver#network....


If I sit any family member down in front of this comment, their eyes would glaze over. Not only is what you mention a PITA, it's impossible for most people.


I'm a programmer and I have no idea what OPs comment means. I keep meaning to learn about networking stuff, but there is always so many other things to learn and since I don't work with devops or networking stuff it hasn't really been a priority.


Don't take it in some wrong way, but most programmers have no idea about networking; for them, IP addresses are just some numbers.

Yes, are explaining to our colleagues what IP address, subnet, route, or interface are.


Most of that comment is Mozilla BS and not networking stuff.

--Someone with a decent understanding of networking


Agreed. Just looked up about trr nonsense and found this 'setting':

> network.trr.excluded-domains

> Comma separated list of domain names to be resolved using the native resolver instead of TRR. Users may add domains they wish to exclude from TRR to this pref. This pref can be used to make /etc/hosts works with DNS over HTTPS in Firefox. Setting network.trr.excluded-domains to include host names from /etc/hosts will make them fall back to platform DNS, which will use the rules in /etc/hosts.

So, rather than using the hosts file, network admins & devs now have to specify 'special sauce' in FF too?

I'm not buying DoH for this reason alone, because it throws out a lot of legacy (albeit always regarded as hokey) for no good reason. If FFox is doing it's own DNS stuff is MUST (at least) do hosts file resolution, imho. Otherwise it leaks names, which kinda defeats one of the main the purposes of DoH: which is to maintain critical privacy in places where it's being abused.


This is so true. FireFox is terrible at spaffing private info at search engines.

Breaking DNS is madness IMHO. Its just more sites that dont work on FF.

Broken is not more secure, its just broken.


You're not alone. That said, I highly recommend reading and referencing "High Performance Browser Networking" by Ilya Grigorik^1, it's accessible, detailed, accurate, and useful in the extreme.

1 https://hpbn.co/


Fire up a Linux VM and check out the named howto. Not only will you learn a lot about dns, you'll have a working server by the end of it.


AFAIK, when one turns on DoH, Firefox's trr.mode defaults to 2. And that's the default behaviour most would want except for the ones using pi-hole et al.


In general, yes, that solves the problem for local domains. But anyone who needs to do anything at all complicated is going to have trouble with this, not just Pi-Hole users.

For example, take your average John Doe who uses Firefox. Not particularly technically competent. A new version of Firefox comes out, and all the Archive.is domains break. Who does he blame for that, and how does he solve the problem?

What's happening behind the scenes is that Firefox switched his DNS address on him without warning. And Cloudflare (the DNS endpoint used by Firefox by default) returns incorrect IP addresses for the Archive.is domains (because the admin of these domains returns fake addresses to Cloudflare from their authoritative DNS server).

Most people are using DNS provided by their ISP, so they haven't seen this problem before. I know about the problem, and my resolver (Unbound) is set to use Cloudflare over TLS for most requests, but sends Archive.is domains to Google's DNS instead. This solves the problem for me. Firefox switching to Cloudflare by default not only breaks sites like this for the average user, it even breaks my workaround that fixes the problem.

(I can't currently reproduce the problem, so maybe Archive.is caved and started sending working IP addresses. But it's the sort of problem that can happen when you start messing around with DNS. Your users will blame you if a site doesn't load in your browser, but works in other ones.)


> the admin of these domains returns fake addresses to Cloudflare from their authoritative DNS server

Why?


They have a beef with Cloudflare over Cloudflare removing EDNS Client Subnet for privacy reasons.


some prior discussion for context -- https://news.ycombinator.com/item?id=19828317


And if it happened to be that Archive.is actually had a beef with John Doe's ISP, who's to blame for that default getting picked?


Not Mozilla.


So in that situation, would Mozilla then be the good guys by adopting DoH and fixing the user's broken network level DNS?

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?


Nah, the lesson is that users are going to blame you when you make low level arbitrary changes that break things when they're not capable of knowing about and fixing the technical problems that arise. The fact that a change might accidentally fix problems sometimes isn't a counter example to that general principle.


Even when the possibility of things getting fixed is substantially more likely than the possibility of things getting broken?

By default Firefox will fall back to the network resolver if DoH can't get the results, so the only way that a situation like this could happen is if someone purposely sabotages the DoH results like with archive.is.

Furthermore, what you are saying could basically be used to rationalize putting any kind of potentially breaking change behind an off-by-default configurable. Do you think the web would be the sophisticated application platform it is today if browser vendors actually had that philosophy? Would that actually be better for John Doe, to make them have to learn about the technical aspects of every new web technology before they are able to take advantage of them?


> the admin of these domains returns fake addresses to Cloudflare from their authoritative DNS server

Well, this explains why Archive.is never works...


Not sure about that; it will still send query to the open Internet first and only when it fails, it will query local resolver.

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.


That's a bit unfair, because this comment was obviously not addressed to the mere mortal. For you family member, a "how to" with a lot of screenshots and red arrows is probably more appropriate.


Considering the amount of people using library or Starbucks internet that needs you to use the local DNS (at least once you initially connect), maybe #2 should be the default? Or is there some risk in doing so?


If your OS doesn’t already detect the captive portal, Firefox will.


Perfect


Firefox has no issues with local domains and DoH. It makes a DoH request first and when that returns nothing it tries regular DNS.


That is an issue.

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.


Half of your comment doesn't make any sense but for the rest of it, its just incorrect. The change in firefox hasn't broken anything, security is certainly improved in combination with other efforts like encrypted SNI. And yes, your dns requests always leave your lan at least once. You can run your own DNS server locally but that dns server has to ask other servers for the data since it can't store a local copy of the entire dns system. A local dns server is just a cache but with a few users its likely not doing any more than your browser cache.


DoH breaks anything that is going on in your BIND or NSD server. It bypasses them, it has broken that. If it does DNS first, then if that fails does /etc/hosts, its broken that too.

If I, or my company, or ISP has anything special in hosts or DNS, e.g. load balancing, name mapping, breaking facebook.com, things like that get bypassed.

DoH over HTTPS is slower than a lookup to /etc/hosts, and probably slower than a lookup to a locally cached DNS resolver.

Security is not improved by FireFox bypassing my network admins DNS rules.

Most DNS queries do not go over the Internet, unless you have DoH or have set special DNS servers. My ISP provides IP access to the Internet and DNS, like almost all ISPs. It not to do with local caching (which does add security), if I query foo.com that query goes to my ISP, not via the Internet, my ISP knows I asked for foo.com and then then the routes my IP packets there.

My ISP has to lookup DNS on the Internet to resolve them if it is not in caches but that lookup is not associated to me.

When I connect to a corporate network all my DNS goes over VPN if any information is required from the Internet again that is not associated to me.

Cloudflare might be running a more secure DNS resolver at the other end than my ISP, but it might not, its rules have to apply to the whole world so they cannot be tuned for me and my security preferences.

After DoH, all DNS goes over the Internet, even quires that eventually are resolved locally. Cloudflare now know I'm going to foo.com and so does my ISP, or VPN provider, I don't see how security has improved. Its just sending information to a commercial partner of Mozilla's in addition to my ISP. Some informationits getting that before my ISP did not get.

Plus HTTPS is not infallible.

DoH is more secure than DNS in plain text over the Internet, but that is very rarely the case.

DNS is also not a significant risk to browser users. I have never had a DNS response faked, to any HTTPS site it would not work, so why bother.

There isn't much risk, its not more secure, and it breaks stuff.


Opportunistic security that can be disabled by attackers is not really security.


I've noticed some problems with eSNI so far unfortunately. Some domains like discordapp.com have some access points with eSNI enabled and some without, so when clients access the ones without eSNI, they believe that they are under attack. I cannot wait for it to be finished and implemented though, it would be a huge benefit for the privacy of millions.


Currently only Cloudflare implements it but that's due to eSNI still being a draft.


Wow, I had no idea encrypted SNI was a thing. That's very good news, because without it, DNS over TLS is pretty useless.


My problem with FF's implementation of ESNI is that they tied it to DoH the last time I checked.

These are separate features and should be decoupled accordingly.

https://bugzilla.mozilla.org/show_bug.cgi?id=1500289


I wonder what the implications will be for TCP-over-DNS, which besides bypassing firewalls, can also provide anonymity in a different way.


TCP-over-DNS, together with the draft RFC for encrypted resolver to authoritative communication, altolows for more end-to-end style encryption. Clients could do their own secure resolving without relying on a central service.


> Clients could do their own secure resolving without relying on a central service.

So in other words: privilege escalation.


Notice that this page says they are only rolling it out in the US right now. I guess it'll be available elsewhere soon?


The features are available everywhere to everybody but are not enabled by default. The only difference for US users is that they're enabled by default.


I'm surprised that they wouldn't block the DNS providers in your country though?


Just 2-3 years ago, normal DNS to CloudFlare or Google DNS were enough to bypass my ISP's DNS redirection. Then those got disabled and while I switched to DoH, many others switched to paid VPNs. Now they've moved up to SNI blocking. They may catch on to the trend and block DoH IPs too if DoH becomes popular.


Frankly, if your ISP is that aggressive, your best bet is a VPN. DoT and DoH will always offer imperfect privacy even with widespread ESNI.


VPNs are routinely blocked in China and elsewhere.


It's for bypassing banned sites


Which country are you in/which countries do you see this happening in if you don’t mind me asking?


Won't help if cloudflare sticks the resolver on the same IP range as regular cloudflare sites. Countries would have to choose to block most of the internet.


I think China has demonstrated that countries are willing to do that.


China is a special case though. They're large enough to populate their own internet with things. Most countries aren't that large.


If the ISP (or Nation) is willing to block google or cloudflare IP-ranges then you will have to be a moving target. Using tor and similar. For normal shitty ISPs thats not an option


Cloudflare and Google's dns resolvers got a lot of adoption bc they provided a way for normal people to get around censorship, but they're inherently censorable bc they're run by centralized companies. There are new initiatives aiming to create a distributed dns layer which are promising like https://handshake.org.


And the distributed DNS layer will get censored soon enough if it gets traction. If you need proof, look at how TOR is doing in china.


Security is not binary, it's a spectrum based on cost. It's the same for censorship-resistance. If Handshake increases the cost of internet censorship for every country in the world, then it will have succeeded even if it's still possible for countries like China to censor it.


China was a special case. There are smaller countries seeking to do the exact same thing now. Russia, for example.


Building your own infrastructure seems viable even for small countries.


[flagged]


> Cloudflare does not block or filter content through the Cloudflare Resolver for Firefox. As part of its agreement with Mozilla, Cloudflare is providing only direct DNS resolution. If Cloudflare were to receive written requests from law enforcement and government agencies to block access to domains or content through the Cloudflare resolver for Firefox, Cloudflare would, in consultation with Mozilla, exhaust our legal remedies before complying with such a request. We also commit to documenting any government request to block access in our semi-annual transparency report, unless legally prohibited from doing so.

https://developers.cloudflare.com/1.1.1.1/commitment-to-priv...


I'm so sad to see Mozilla move forward with this massive attack on user privacy.

Firefox DoH is snake oil, plain and simple. It sends all the users DNS queries to Cloudflare, adding a new party which can surveil the user's traffic (and can be legally compelled to do so and not disclose this fact)-- providing a convenient choke point to save spies and hackers the trouble and exposure of extracting the data from tens of thousands of individual ISPs.

Simultaneously, it does not protect the user from monitoring by their ISP or parties situated there because the user's destination IPs remain unencrypted, as well as the hostnames via SNI (for cases of shared hosting, e.g. on cloudflare, where the IP alone wouldn't be enough).

At the moment you can disable this across your whole lan by blocking traffic to 104.16.248.249, 104.16.249.249, 2606:4700::6810:f8f9, and 2606:4700::6810:f9f9 and by DNS blackholing use-application-dns.net and cloudflare-dns.com.

iptables -t raw -A PREROUTING -d 104.16.248.249 -j DROP

iptables -t raw -A PREROUTING -d 104.16.249.249 -j DROP

ip6tables -t raw -A PREROUTING -d 2606:4700::6810:f8f9 -j DROP

ip6tables -t raw -A PREROUTING -d 2606:4700::6810:f9f9 -j DROP

And if you're using bind:

zone "use-application-dns.net" { type master; file "/etc/bind/db.empty"; };

zone "cloudflare-dns.com" { type master; file "/etc/bind/db.empty"; };

Or unbound:

local-zone: "use-application-dns.net" static

local-zone: "cloudflare-dns.com" static

But there is no guarantee that these mitigations will continue to work.

[Edit: Aside, this comment and many/most(?) comments on this thread were moved from a more recent thread with a headline "Firefox turns on DoH as default for US users". The new title which omits the on-as-default, is kinda burying the lead.]


Your ISP is literally selling this information right now in the US. What are you even talking about? Use google if you don't like CF, or just disable it!

Do a little threat modeling here please. Let's say CF sells this data, what do they know about you other than your IP and the sites you visit? While your ISP,employer,school,etc... Can tie that activity to you as a person. Being compelled legally? I did not know privacy meant breaking laws, suddenly law enforcement can't do the same thing with your ISP dns?

This is not adding a new party that can surveil you, this is reducing risk by separating who can see your DNS from who can see your traffic. The idea is to have eSNI ubiquity to where TLS traffic will conceal the sites you visit while DoH will conceal the traffic metadata. Oh, and beauty of DoH: you can run it through a web proxy, and if you have alot of users behind a NAT it becomes very hard to pin point which actual machine generated the DNS lookup.


Sorry for channeling the dude here but that is just, like your opinion man.

I think many of the critical voices now are coming from the EU. We have data protection laws. The ISP can't just sell browsing data. That has been illegal since before we had data protection laws, that is actually legally the same as opening other people's letters and reading them. So ... different threat model over here.

I am always using the US-EN Firefox version because frankly why would I use translated software when I can understand and use the original.

I hope you can see how it might be of concert to me whether Mozilla decides to give my browsing data to Cloudflare, whom I have about as much reason to trust as GCHQ or the NSA.


I'm an EU citizen as well.

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.


Unless you always use VPN, they can still do that, even with DOH.

And if you use VPN, they can see your traffic.

Personally I trust my ISP more than some random VPN provider on the net.


First of all we are not talking about the trustworthiness of VPNs, that's a separate discussion entirely. And no, I don't trust my ISP more than I trust my VPN, but I understand your mistrust as VPNs are indeed not so private as they are marketed. But imo this is throwing the baby with the bathwater.

Go to Germany, download a movie either from the Pirate Bay or see one from one of the many illegal websites streaming content and prepare for a letter (delivered to your home address) with a huge fine and a legal threat within a month.

Not that I'm a huge fan of pirating content, even if some cases like Sci-Hub have the moral high grown, but this goes to show just how trustworthy an ISP is, in an EU country with some of the best privacy laws ... and in such cases a VPN is absolutely mandatory.

---

DoH hides your DNS queries — if you visit an HTTPS website, the traffic might be protected via HTTPS, but the domain name is clearly seen.

Of course, the ISP still sees the IP you're communicating with, but due to SNI and industry practices nowadays of putting websites behind CDNs, IPs don't necessarily reveal the website you're communicating with.

DoH also makes it harder for ISPs to block or redirect your access to certain websites. For instance it makes it harder to block Pirate Bay based on the whims of your local government. Now certainly Cloudflare can also be compelled to block websites like Pirate Bay, but the DoH service you're communicating with is customizable, you can pick whatever service you want and just like VPNs, I predict there will be plenty of privacy respecting services to choose from.

And DoH is not foolproof, it doesn't solve all of our privacy needs, it's just a piece of the puzzle, but a necessary one.


Sure in that case makes sense to use VPN.

> I predict there will be plenty of privacy respecting services to choose from.

Why, where is the money in there ? Sure there might be some, but many ?

Call me cynic but I don't think google(one of the biggest public DNS servers atm) or clodflare(probably second biggest) are providing this service out of goodness of their harts.

If you worry about DNS that much, running your own is not that hard (I am running one at home* , and one at the place I work).


I don't know why Google and Cloudflare provide this service and I don't really care, because it's irrelevant.

DoH is first of all a protocol. If you run your own DNS resolver at home, surely you'll be able to run your own DoH server too.

Also your requests will no longer be sent in clear text, which means that a Wifi administrator at your local coffee shop won't be able to see your queries and responses, which with the regular DNS protocol are in cleartext, in which case your home DNS server does not help — unless you're on your own network in full control of your router, or run your own VPN, communications with your home DNS resolver are just as vulnerable.

The value of something like DoH is clear, regardless of the motivation that Cloudflare and Google have for providing such a service for free.

---

Speaking of which, accessing pirated content is not the only case I worry about — another problem I have with my ISP is that they serve me a 404 Not Found page filled with ads on domains that aren't available. This is in an EU country.

Also back when HTTPS wasn't forced on Google, the searches were logged and people were automatically flagged for problematic queries and then potentially monitored for years. One of the topics that triggered automatic flagging was child sexual abuse — I know because I helped a local campaign, building an awareness website, etc, only to be informed of such practices by an acquaintance working for our internal security agency.

And while today this may happen for legitimate reasons, tomorrow it might happen for people criticizing the government. Look no further than countries like Turkey or Hungary.

Personally, coming from communism, I fear the nanny state more than I fear big companies from other countries.


> Personally, coming from communism, I fear the nanny state more than I fear big companies from other countries.

I am from Slovenia and I know exactly what you mean, and agree 100% with that.

I just think that in the end POE is worse, since I think it will result in concentration of something that was widespread (plenty of small ISP's and providers), into few bigger and easier to backdoor providers. So it will be easier to monitor then before. And I don't think think that western democracies and "democracies" will just throw in their towel.

I trust Cloudlfare and Google less than I trust my ISP, if nothing else their budget (and competence, and reach) is much lower(isp's).

I mean gmail and outlook are much more competently run than most ISP's and businesses ran their mail servers. I am afraid something similar can happen here.

> DoH is first of all a protocol. If you run your own DNS resolver at home, surely you'll be able to run your own DoH server too.

Packets never leave local network. The advantage of DoH is that it's over https, so if you don't control your firewall you can still use it. But if you control your own network, DoH is not that useful, since you still have to support old DNS for all the applications and devices that don't support DOH. If someone can listen on your LAN you have bigger problems than someone being able to intercept your DNS queries. Not saying there are no advantages, it just isn't a priority.


No, it is not an opinion. It is technically accurate, but may not be relevant to your particular situation.

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?


I want the legal policy to be based on where I use it from, not which language I download. As a .nl citizen I personally hate language localization, set my locale to en_US.UTF-8, and always ensure I download the international versions of my browser. I would expect at the very least the legal policy to be tailored towards where I download it from, but preferably where I use it from.


> > I am always using the US-EN Firefox version

> 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.


> I am always using the US-EN Firefox version because frankly why would I use translated software when I can understand and use the original.

This is maybe not the topic of discussion, but the argument is that your computer is your tool, and the computer should speak your language and adapt itself to you, and not the other way around. For this reason I like and prefer software that speaks my native language! However, I don't have patience for bad translations, and in those cases I'll avoid the translated apps. Not a problem for Firefox!


I absolutely loathe software in my native language. I will go out of my way to avoid it, because it makes everything more complicated.


From my point of view translated software often just means that googling errors is harder


It's worse than that. Some words did not exist in the target language (the computers are relatively new compared to the age of the language) so they had to be created. Nothing is more annoying than to search for words which make no sense.


Why do you think english is any different? Silly words were created for new concepts in computing (as in other fields) in English too.

You just don't notice how silly all the new words are (like bit and byte, and "gigaflop" and so on) because english is a prestige language and that it is a foreign language.


But using my native language makes troubleshooting and following tutorials much harder.

Using English is the path of least resistance


> What are you even talking about?

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.

https://news.ycombinator.com/newsguidelines.html


I don't get how that's a swipe, it is not a rhetorical question, my intent there is to literally ask what he's talking about given the arguments made. I did not attack the commenter personally,"brigade" or an ad-hominem argument. I think you might be misunderstandig our conversation here, this being a text medium it is hard to comminicate tone and body language. It's not uncommon for me to say a phrase like in technical arguments with people I get along with very well. This is a technical discourse not a interpersonal one, my disagreement is with the supposed factual statements not the person as such how can it be a swipe against them?

That said, I will avoid that specific phrase on this site as you asked.


It's easy to get hung up on specific words, so it might be easier to consider meanings. What is the meaning of the phrase "What are you even talking about?" Is it a question? If so, what answer were you hoping for?

If I take you at your word that it's not rhetorical, then I could replace your question with "what do you mean?" – however, if you don't know what the poster means, why does the rest of the comment continue as if you understood them perfectly?

The more plausible interpretation of "what are you even talking about?" is "you are spouting nonsense". Yes, your wording is more polite, but the meaning is the same. The only way a polite insult isn't an insult is if you assume the person you're insulting doesn't understand it. Kinda makes it two insults, really.

All discourse is interpersonal, and how you disagree with someone's statements has interpersonal implications. I think your argument misses the point. I also think your argument is disingenuous and avoids engaging with substance in order to project misunderstanding onto the person trying to help you.

Both of those are opinions about your statements. Which do you think best exemplifies the following?

> Be kind. Don't be snarky. Comments should get more thoughtful and substantive, not less, as a topic gets more divisive. Have curious conversation; don't cross-examine.


It's not rhetorical and it is not literal either. A rephrase can be "what you are saying makes no sense for the reasons I am about to lay out and I would like it if you can address my points below, based on my understanding the argumets you made lack basic coherency, please tell me what you think of my counter-argument".

If this was a work email in a super-uptight place I would say something like that. Had I known that simple phrase I use all the time would be so controversial I would have avoided it or rephrased.

You chose to question my motives and assume the likely explanation is that I am atracking the person instead of their are argument. I am insinuating that their argument sounds ridiculous but I am not implying that as a fault of their intellect or personality but a lack of perspective where sharing my perspective might help them change an opinion.

I will not defend my personality and motives being questioned when I made no attempt to do so, I also did not the attack the person themselves in anyway. You should not assume malice. I think @dang saw me break rules in the past over one of the politcally charged threads and assumed it was in my personality. Feel free to review my post history on technical topics like this, I make best effort to avoid ad-hominem or anything resembling an insult. Presumption of malice itself is unfair.

I have nothing to gain by attacking anyone. And even if I did, you should look at the context od what I said after that phrase to find out what my intent was. If I don't promote myself or say anything against the person why are you assuming malice?

What about when I said "please try some threat modeling here" is that being snarky as well? It can be if you assume malice. I hope no such assumptions are made.

Either way, I did make a mistake: after years on HN, I keep forgeting that it is to be treates like a corporate/work environment. Two friends using my ever so controversial phrase would not assume malice or police for snarkiness, but two coworkers or paries of a business meeting/engagement would.

I will be careful to be more aware of the environment.

Oh, and not all discourse is interpersonal. It is done interpersonally but the subject of the discourse is does not have to be the other party themselves,their intellect or character (and was not the case in my response -- very obviously)


A polite way to say this would be "Can you clarify what your concern is?" or "Can you clarify what you're referring to?". The original phrase drips with disdain. If that's not the intended sentiment, then well, that's a challenge of conveying emotions in text. You could always include an emoji to better convey the meaning :-)

Some phrases come with a built-in sentiment that people will assume exists unless it's overridden.


A rephrase would be "what you are saying makes no sense at all" I think that can equally be misunderstood. It does drip of disdain, you are not misunderstanding that part, you (and @dang) are misunderstaning the subject of this disdain which is the perceieved lack of logical coherence on my end. You're taking it as if I meant that if I am right and the other person is wrong, their knowledge or intellect should be discredited, hence why dang said it was a swipe. To me, it simply means (if I am right, which may not be the case) they lacked the perspective which I laid out as an argument afterwards. The purpose of the discord is so we gain new perspectives that change our understandings and opinions on the subject matter. I don't even remember the nick of the person I replied to, and I made sure that my identity is not visible on HN (outside of correlations people can make),I have absolutely no reason to one up anyone.

I still maintain it was clearly not a swipe purely due to the fact that I made no attempts to attack the persons personality or intellect or to promote my own, as such my intellectual honesty and purity of intent should be given the benefit of the doubt.


I think it's a good call out to keep in mind the guidelines, but technically the original comment also breaks guidelines.

Two wrongs don't make a right, but I would suggest trying to avoid the appearance of personal bias when calling out guidelines infractions on a comment without also calling out infractions within the context equally.


I don't see how the GP comment broke the site guidelines. "Snake oil" is close to name-calling, but I don't think it's really over the line, and if we started moderating HN comments for that kind of thing, there would be a huge backlash from the community. Is there something else that I missed?

These things are matters of degree in any case, and "what are you even talking about" is clear cut.


Specifically I was thinking about this:

> Don't be snarky. Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.

The original comment had equally strong phrasing on what amounts to an informed opinion:

> I'm so sad to see Mozilla move forward with this massive attack on user privacy.

The insinuation that this is an attack on user privacy is a bit of an escalation in description. In truth much of the following information describes a potential threat to user privacy, for it to be an attack one would have to provide evidence of intent.

> Firefox DoH is snake oil, plain and simple.

I would argue this statement could be construed as snarky (at least that is how I interpreted it).

Generally speaking, I don't consider myself an expert, but I do think I have a more informed opinion than most (and no doubt many HN readers have even better informed opinions than my own). And while I do see the merits behind the points raised in the original comment, I do think it could have been presented better.


Person a: I like the blue stuff in oranges Person b: what are you even talking about? Oranges do not have a blue inside.

Now what is a swipe about this or breaking a guidline. It did give the impression ( to me at least) as if I was being picked on. But I think in reality you probably misunderstood the tone and intent. Of course this is just my opinion, what you say is the law here and I intend to abide.


I believe you, but intent unfortunately doesn't communicate itself well in internet forums, so the burden is on the commenter to disambiguate.

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.


It wasn't my intention to make an inflammatory comment.

My statement was strongly worded, but it is my informed opinion as a subject matter expert: As someone who worked in ISP networking for over a decade, worked at Mozilla, and work on network protocol, I feel that I'm entitled to have a strongly stated opinion and I believe I substantiated it in my post. I'm also happy to have a polite discussion justifying it further.


I'm glad your intention was not malignant! I didn't mean to imply it was, truthfully I was just trying to also contribute to keeping discourse civil.

See my comment above about specific things that (I personally think) could have been phrased a bit better; I am not saying you're comment was unhelpful or deserves reprimand. Just wanted to point out to the comment(er) that both comments had aspects that could have been phrased a bit better and chastising one is not as helpful to improving discourse as providing complete feedback in the interest of being fair.

Disclaimer: I deleted a previous comment because on re-reading I think I meandered a bit and thought I could do better.


I agree with the other person who replied to you. I think you should call out the original commenter as well.

By only responding to one person it gives the impression that you think the first person did nothing wrong.


> Your ISP is literally selling this information right now

No, mine is not.

> Use google if you don't like CF

Google is no better.

> or just disable it!

It is never okay to hijack my DNS lookups. Posting a note someplace about how it can be restored does not change the fact that you hijacked it, and does not make it okay.

> This is not adding a new party that can surveil you

Given that the DoH provider is a new party with which most of my requests had no contact before, that is an absurd claim.

> this is reducing risk by separating who can see your DNS from who can see your traffic.

No, it is not. My ISP can still see the domain names of sites I visit, via both SNI and OCSP. They can also deduce the same information in most cases, via address correlation. (Thankfully, I chose an ISP that respects privacy.)

This change quietly hands my lookups over to another party as well. If I hadn't noticed the announcement, or didn't have enough technical knowledge to fully understand and revert the change before it went live, my lookups would be pwned.

> The idea is to have eSNI ubiquity to where TLS traffic will conceal the sites you visit

I don't care what your idea is for the future. It doesn't exist today, so is not relevant to what you have done today.

(And even if it did, it would not excuse hijacking my DNS lookups.)


They're not doing it in secret. Use a different browser if you don't like it, or fork it.

Mozilla have made a value judgement that DoH is more useful to end users than the supposed privacy loss. You're free to disagree, but neither of you is objectively correct.


> They're not doing it in secret. Use a different browser if you don't like it, or fork it. They are not doing it in plain sight either.

> Mozilla have made a value judgement that DoH is more useful to end users than the supposed privacy loss. You're free to disagree, but neither of you is objectively correct. Mozilla made a lot of "value judgement" lately just like Chrome. That's why i try to switch to seamonkey.


IMHO Mozilla have made a bad call justified by misguided security.

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.


> or fork it

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.


> My ISP can still see the domain names of sites I visit, via both SNI and OCSP.

Encrypted SNI and OCSP stapling solve those problems.


They see the SNI but not the host. eSNI would help but so do CDNs (even with ocsp/crl since hundreds of sites use a single cert. Domain fronting is getting more common too


"Your ISP is literally selling this information right now in the US"

Your ISP will literally still be able to sell this information after DoH is rolled out. Because they can see what IPs you're connecting to and in most cases hostnames can be trivially and automatically determined knowing only the IP.

Unless we centralise HTTP through a handful of gateways like we're doing with DNS (hello Cloudflare). At which point, why even bother calling it the web anymore.


Very limited with TLS. With webhosts, the PTR record means little. CDNs also obfuscate your destination. Shared hosting sites only care about the host field in the encrypted HTTP as well. Especially given the oversaturation of IPv4.

Keep in mind, it's not just what you visit but how often as well and a lot other details (dns is cached)


> Very limited with TLS. With webhosts, the PTR record means little.

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.


It’s much worse than you think: https://news.ycombinator.com/item?id=22418005


> Do a little threat modeling here please

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.


> > Do a little threat modeling here please

> Yes, lets do some threat modeling. In the first model we have the ISP that host a DNS resolver. The traffic goes from the client to the server hosted by the ISP.

> In the second model we have a CDN that host a DNS resolver. Where is the CDN hosted? At the ISP. The traffic goes from the client to the server hosted by the ISP.

hosts : files,dns Damn it. When the bloody browser bypasses the OS then it is really a big problem.


> Your ISP is literally selling this information right now in the US. What are you even talking about?

Every time Firefox starts up it probably phones home to check for updates. The incoming request is traceable from the user's IP and Mozilla could figure out if the user is with a privacy-violating ISP: they could then only enable OS-bypassing DoH for those users.

Those who run Firefox in corporate networks would be unaffected, as would those who are were 'good' ISPs.

Also, as someone in Canada, I downloaded the "English" version of Firefox, which probably meant "en_US" locale: guess what, I'm affected. As are plenty of less technical people who don't understand about going into about:config and changing things to "en_CA".


> Also, as someone in Canada, I downloaded the "English" version of Firefox, which probably meant "en_US" locale: guess what, I'm affected. As are plenty of less technical people who don't understand about going into about:config and changing things to "en_CA".

The en-ca locale was only added to Firefox in September 2018, I think it's the default for any new downloads since then, but FF won't automatically change the locale for existing installs.


Can't you just disable DoH?


Sure, my point was just tangential to clarify on the availability of the en-ca locale for Firefox. I don't even know that DoH is based on the installed browser's locale in the first place. (I'd guess that it isn't, as I'd expect many non-US users use the en-us locale.)


> Can't you just disable DoH?

I'm just going to tell my mother in her 60s about editing about:conf settings.

This shouldn't be opt-out.


Your ISP can still see the IPs that you are talking to... What are you talking about? They can even see the url even if you dont use them as your DNS


> They can even see the url

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.


ESNI is not in use yet (or just doesn't work). Start up tcpdump and check yourself.

At best even it were currently use it only provides protection for sites which are hosted behind DOS mitigation services. (usually cloudflare...)


You need the right TLS lib for it to work, browsers support it. I've seen big sites like facebook and cloudflare use it.


You can check it here:

  https://encryptedsni.com/ -> https://www.cloudflare.com/ssl/encrypted-sni/


ESNI is still in draft.


Quite. I didn't mean to imply a host/ip header wouldn't leak today - but I see how my comment can be read that way.

In fact, siblings point about cf (cloud flare) is relevant - as cf eats the world, SNI will potentially be more of a problem; if you connect to site A via IP a, and B via ip b - not much is revealed if host headers A and B leaks, given that traffic to a and b is already obvious. But when you connect to cf on a "nearby" IP c, it suddenly becomes more of a problem that host headers for A, B, D and E are leaking. Not necessarily worse than when your ISP could see you talking to IP a and b - but worse in the sense that you reveal some information to your ISP that would otherwise only be known to cf.


so we agree the ESNI is not in used?


Note that US ISP "Comcast/Xfinity" does not, so at the very least, that's one safe harbor amidst the rest.

https://corporate.comcast.com/stories/privacy-with-comcasts-...


Cloudflare states the same thing. In fact, Cloudflare provides much more detail than Comcast/Xfinity [0]. And, personally, I actually believe Cloudflare.

If I have to choose between the two companies it's a no brainer. This is Cloudflare's business, and their business relies on them upholding their privacy promise. Comcast/Xfinity has, in the past, engaged in DNS hijacking [1]. Comcast has had the worst ACSI score over all other businesses in the US more than once and consistently ranks very low [2]. Comcast won the worst company in America in 2014 by the Consumerist [3]. Comcast has intentionally deceived it's customers as we understand due to lawsuits [4].

I'm not sure what sort of jaded world we live in if one can say Comcast/Xfinity is a "safe harbor amidst the rest" with mountains of public information stating the complete opposite.

[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...


Cloudflare's business lost them over $100 million last year alone. The way they operate right now is not a viable business, and we have no idea what they will change when they need to become one.


Maybe you're new to the tech/security space, but the majority of companies operate at a loss as they grow and pivot their business. If you follow Cloudflare they've only recently begun to start to sell into the enterprise space with new products as in the SASE space and beyond their traditional DDoS/WAF/encryption plays. Even with those "legacy" products - Cloudflare never heavily sold into large enterprise compared to more notable names in the hardware security space that they now are beginning to compete with. Their business is evolving to include field sales that are aligned to selling in this manner, which is relatively new for Cloudflare (comparatively).

But just stating that Cloudflare is operating in the red currently isn't a justification for anything as it doesn't mean anything positive or negative without understanding their operational business model and targets.

I'm guessing your statement is making a leap by assuming that because Cloudflare is operating at a loss currently that they're going to sell your data against what they publicly state in their privacy policy? For a growth company - that would be one of the dumbest things for them to do. Because if they are caught in that lie they will sink themselves.


No, it clearly says that if they haven't figured out a business model yet, the business model they will end up figuring out might just as well be selling your data, so it's maybe not wise to make the internet depend on them not doing so.


Let's be clear here...

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.


> If they do, then we can all have that conversation.

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!


> That is not how arguments work.

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.


> Generally arguments are based on facts. [...]

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?


How do you think Akamai makes money? CF is a competition.


That's a blog post, not a privacy policy. Not to mention the phrasing still allows for them to do this, as long as the information isn't personally identifiable.


I trust Cloudflare and Google (the other major DoH proponent) not to sell my data, because they have no need to do so. They are subject to law enforcement inquiries just like everyone else, so this does nothing for privacy in that regard (and actually increases the attack surface).

This also does not separate who can see your DNS from who can see your traffic, in fact it consolidates it, and this is why both Google (who controls the browser) and Cloudflare (who serves a large portion of the internet) are proponents of it. It allows them to aggregate DNS information alongside request information in a way they could not previously.

I am aware that they both have policies in place which purport to prevent this behavior. It would certainly not be the first time Google violates their stated policies in the mission of serving advertisements, or the first time Cloudflare aggressively consolidates internet infrastructure to the detriment of the open web.


> I trust Cloudflare and __Google__ (the other major DoH proponent) not to sell my data, because they have no need to do so.

Isn't Google's entire business model... data collection? Maybe Google won't sell the data, but they'll use it and sell the information they gather with it (i.e. ad targeting). I'm not sure this is meaningfully better than selling data (though there are definitely arguments to be made there).

AFAIK CF isn't in the business of ads and really data collection is just a waste of their disk space.


It's also yet an other instance of the web browser taking over something that (IMO) ought to belong to the OS. Now with DoH if I have DNS issues I have to figure out if it's related to the browser's DNS or the system DNS. I can't use command line tools like dig or ping to troubleshoot the issue because it's not what the browser is doing. If DoH is so great I want to enable it for all my applications, not just my web browser.

People, let's just rip off the bandaid and make Chrome and Firefox bootable already, who needs the kernel overhead when the browser is going to reimplement the entire stack itself anyway. Also let's just make TCP only work on ports 80 and 443 because clearly the rest doesn't really serve any purpose anymore.


You can definitely do DNS over HTTPS/TLS for everything if you run your own DNS server, either locally or somewhere on your network. I do this, and it works great, both methods have their own advantages and disadvantages of course.


Chrome is bootable already. ChromeOS. :P


> We continue to explore enabling DoH in other regions, and are working to add more providers as trusted resolvers to our program. DoH is just one of the many privacy protections you can expect to see from us in 2020.

Cloudflare is just one of the initial providers and they indicate that they are adding more. Also, I'm assuming you can add your own custom provider based on the screenshot in the article. You can just disable the feature as well.


"You can just opt out" is the same tired line that in former times Mozilla has fought against.

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, 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.


I trust my own DNS provider much more than I trust Cloudflare to be honest. Also, most DNS requests over that “insecure protocol” happened over a single network hop or two and never left the infrastructure of the ISP.

Cloudflare is now a public company and they need to aggressively monetize their services. Selling browsing data is a lucrative business and becoming “the” DNS provider for most users (while locking out all other players) is a great way to build a data monopoly.

Not to mention that being the number one DNS provider will give them many opportunities to break domain resolution for users that don’t use their DoH service, as they also control the DNS entries for many sites (they could e.g. make propagation via normal DNS slower or start providing only a limited set of entries over “insecure” DNS).


American ISPs can and do sell your data legally. I don't really trust my ISP (I run my own DNS server at home and tunnel its requests over to a cloud VM), but I trust Cloudflare even less.


I trust my ISP but not American companies. They roll out only in America but obviously it's coming, and they use locale to detect it? My locale is set to en_US too, surely I'm not alone doing it because of translated software. Firefox has a small market in America anyway and America is not the world. We know big tech is in bed with your three letter agencies.


"Legally" is dubious. Intercepting any private wire communication is a clear violation of federal law (e.g. 18 U.S. Code § 2511), and a violation of the law in many states (e.g. CA PC 631).

Unfortunately, the US government is one of the larger users of ISP surveillance activities, benefiting through the purchase of private data as well as using administrative subpoena to obtain the data collected by ISPs without due process or meaningful oversight.

This creates a conflict of interest which I believe is preventing the US from zealously enforcing existing criminal law which would be otherwise sufficient to significantly reduce surveillance by communications providers.


Are you sure about that? This passed in 2017 and I don't think it's been reversed:

http://clerk.house.gov/evs/2017/roll202.xml


Hm. FCC getting a ruling overturned that strengthens the law doesn't change the existing law, however.


Wow, that's one polarized vote…


I dont use my ISP as my DNS provider, I have a custom setup using PiHole and other methods to provide secure DNS Resolution

Firefox should not be forcing this shit on me, time to search for yet another browser that will respect users. Mozilla is clearly more interested in commercial viability via their partnerships with large corporations (like CloudFlare) then in protecting Users


The only way to solve the ISP DNS inspection problem is by one of:

* Using DoH. For this to work with PiHole, you need to have a DoH resolver on the device, and then instruct the PiHole to recurse to that resolver instead - possibly your own in a VM somewhere?

* Using a permanent encrypted VPN to your own machine in the cloud and routing all DNS through that, then recursing to some DNS that you trust.

* Write your own encrypted protocol that communicates with some machine in the cloud.

Anything else and your ISP/evil-state-actor is able to to see your DNS traffic in plain-text. PiHole and DoH approach the problem at different OSI layers, you ideally need both.


>>Anything else and your ISP/evil-state-actor is able to to see your DNS traffic in plain-text

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.


Cloudflare aren't the only people running a DoH endpoint


DNS over TSL (DoT) is a much better alternative to DoH, at least when it comes to the ability to be tracked.

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.


> DNS over TSL (DoT) is a much better alternative to DoH, at least when it comes to the ability to be tracked.

> 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".


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...


DoT only solves the SNI problem during the DNS request itself. It doesn't do a thing about the SNI during the request to the actual website, which is where all the privacy concerns are.


DoT only solves the SNI problem during the DNS request itself. It doesn't do a thing about the SNI during the request to the actual website, which is where all the privacy concerns are.

Sure, but until we have encrypted SNI, which is in draft, meta data is going to leak, but that's a separate issue from either DoT or DoH.

But because DoT doesn't use HTTPS, you don't get some of its downsides like using cookies for tracking, for example.


DoH (edit from DoT) doesn't use cookies, it is stateless. But your original comment didn't mention that anyway, it only mentioned SNI.


From "The Big DNS Privacy Debate" [1]:

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...


Is there an indication they are moving in that direction already? (Genuine non-sarcastic question)

They've built up a considerable amount of good-will in developer communities. Is there some historical indicator with cloudfare that suggests they are going to blow it all on their path to monetization, or are we extrapolating from other VC backed companies (which may be an understandable position to take, but why?)


Yes I think they will. Their positioning in the VPN, DNS, CDN and (soon) enterprise networking space will give them enormous visibility into a large fraction of what is happening on the Internet, and I simply cannot believe that a profit-oriented company will turn away from such a market opportunity.

Cloudflare isn’t really known as a privacy champion, they always put more emphasis on security, speed and reliability.

From a privacy perspective it’s pretty horrible what they do as well, because they decrypt and inspect all traffic between their customers and those customers users. Security-wise it might be great, but don’t confuse security with privacy.

I really hope that I’m wrong but I’m skeptical that Cloudflare will turn down such a big opportunity, and this move with DoH really seems to confirm this.


Mozilla has previously noted that Cloudfare is contractually obligated to keep the traffic private and not monetize or share it. That's not perfect, but without a law requiring it that's about the best you can get in the U.S. (assuming the contract has teeth in the penalties it imposes).


I'd be willing to accept a lien on the homes of the senior cloudflare and mozilla executives with a contract that will forfeit the value of their homes and allow me to sell them and donate the funds to charity, should it be demonstrated that Firefox-Cloudflare DoH is being used to surveil users.

There are many things that could be done. The problem is that the promises they make sound grand but aren't real, they wouldn't put the value of their homes at risk (nor would I encourage them to, I'd encourage them to not put themselves in a position where they could be forced to compromise the privacy of the public like this) ---- yet some user's lives can be put at risk by privacy-failures of their service.


That would certainly give a new meaning to "we take security seriously" -- one I would also love to see!


That is pointless, Contracts are only valid if they have teeth, and I highly doubt CloudFlare agreed to any contract that exposes them to huge financial liability

So the question is "What happens when CloudFlare violates the contract" do they get a strongly worded email from Mozilla?

bad PR?

Or is it s bankruptcy causing event for the company. Anything besides that means the contract is worthless


It's interesting how bubbles work.

In my world, everyone has a story about how an obscure but interesting to surveil service that they were involved with was DDOS attacked and immediately cloudflare sales was showing up offering to mitigate the attack for free by MITMing their traffic. ... Even showing up on the IRC channels of open source projects. I've personally witnessed it three times.

Even if it weren't for the fact that it would be gross incompetence if the NSA hadn't compromised cloudflare up, down, and sidewise since it's such an attractive target, the surveillance based sales-leads approach used by cloudflare has convinced a lot of people that they're engaging in a protection racket. Not just technies, either-- I've heard from executives who pay for cloudflare service that they think is a protection racket but they pay anyways because it's just a cost of doing business.

[I don't personally think it is, but I think that cloudflare is unethically creating a situation where some customers will believe this and pay as a result.]

It's such a lovely setup for a state attacker. Step 1. Compromise cloudflare (either by getting insiders into it, or by hacking them). Step 2. DDOS attack the thing you really want to monitor. Step 3. Cloudflare sales shows up and helps onboard the victim onto your borrowed surveillance platform.

People think that kind of stuff about AV companies, but at least AV companies aren't showing up within minutes of an attack saying "Gee, isn't it so terrible that you've got a virus. We've got a cure for that!". At least AV companies mostly don't send your data all back to their servers where god knows what happens to it.

Even where the problem is usually just a volumetric DDOS, the cloudflare standard solution is a full encryption unwrapping layer-7 MITM.

DoH without cloudflare would also gather complaint but the fact that the default centralized panoptiresolver is cloudflare contributes a lot to many people's discomfort.

So, I don't think cloudflare has amassed much goodwill at all, and that's even before getting into how their 'protection' made much of the internet unusable behind tor or other anonymization proxies.


> So, I don't think cloudflare has amassed much goodwill at all, and that's even before getting into how their 'protection' made much of the internet unusable behind tor or other anonymization proxies.

Funnily enough Cloudflare supports DNS over Tor[1][2], and I think they are the only one. Please let me know if there are others!

[1] https://developers.cloudflare.com/1.1.1.1/fun-stuff/dns-over...

[2] https://blog.cloudflare.com/welcome-hidden-resolver/


That's pretty cool!


Yeah, really hoping someone else will come along and give me alternatives though. Cloudflare is a bit iffy.


This is the most convoluted conspiracy theory I've read so far this decade.

You profess not to believe these theories, or at least not the first one. So why then repeat? It's just more untruths poisoning this debate, like any other going on these days.

And how does Cloudflare get the blame in your telling of this story, when it's your unnamed sources "you've heard" believing paranoid stories? DDOS were a thing before Cloudflare, and the incident numbers haven't much changed. So if it's Cloudflare doing it all now, they must have simultaneously convinced everyone else to stop.

The idea that their salespeople showing up when you're under attack is similarly strange: While I might agree that it feels somewhat creepy, is there any doubt that these things are easy to notice with some saved twitter searches and a google alert? It also strikes me as a potentially quite useful sales tactic. And yet, even though it's feasible and effective, they are supposed to forgo that channel to stop others from engaging in obviously flawed reasoning?


> This is the most convoluted conspiracy theory I've read so far this decade.

You must not get out much. :)

> things are easy to notice with some saved twitter searches and a google alert?

They are not doing this through twitter searches or google alerts. They show up when there is absolutely no mention of it anywhere, even sometimes when the attack is largely ineffective. Expectations like yours-- that they could only discover them from public sources-- probably contributes to people believing the attacks originate from cloudflare.

They use sampled netflow data from ISP to detect large scale DDOS attacks (presumably buying the information from arbor networks or similar, where they don't have their own coverage).


Pre Snowden you might have had a point.


My domestic IPS is owned by a public company and I'm sure they need to aggressively monetize their services too. My point was just that you ultimately have to trust someone. Not trusting CloudFlare is a perfectly legitimate position to take.


If Cloudflare sells their customer data then wont they be sued by Mozilla for breach of contract?


>Formerly your browser still "phoned home" to your default DNS provider, using an insecure protocol.

This is kinda painful to read, to the point where I'm not sure if it's intentionally misleading;

DHCP will give you a DNS config, that DNS server can be local, remote, it can support DNSSEC or DNS over TLS (yes, that's a thing[0]). I even have configurations where a local DNS resolver on my machine (DNSMasq/unbound) would query _different_ recursive resolvers based on the domain I'm requesting.

DoH takes away huge amounts of configuration, and the ability to locally host DNS and ensures that a central body gets your DNS requests. The only "opt-out" in the current system is not using DNS at all, which is still an option. (NETBIOS/mDNS/Hosts)

[0]: https://developers.google.com/speed/public-dns/docs/dns-over...


I think this is an unfair response.

> 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.


> Maybe a nitpick but i doubt dhcp is going to hive you a local dns server

Nearly every consumer-grade router on the market hands out IP configurations where said router is configured as a DNS server (the router then usually is configured to forward requests to the DNS provider of your choice, which is usually the ISP's DNS servers, depending on the technical ability of the person that set the router up). This is useful for things like accessing devices on your local network that have a GUI accessible via a web browser by hostname rather than IP address or, in the case of Netgear, intercepting requests to routerlogin.net and redirecting them to the router's configuration page instead of some page on the Internet.

If FireFox starts to ignore the OS-level DNS configuration, then these things are going to break and consumers who don't follow these things closely aren't going to know why or how to fix it.


> Maybe a nitpick but i doubt dhcp is going to hive you a local dns server

0_o Weird doubt,-- thats why DHCP can give you a DNS server. Otherwise, DNS discovery might as well work by just defining some /32s that always get routed to a nearby DNS server. :)

My DHCP servers at home give me a local DNS server... any corporate network that also has internal private naming will necessarily be handing out a resolver internal to that network.


I guess i was interpreting local in the sense of localhost. Which, fair enough, in context that is a silly way to interpret local as local network makes much more sense in context.


Ok. Would you accept "_potentially_ insecure protocol" then? DNSSEC for example provides no encryption.

fwiw I agree with you about a central body getting all out DNS requests.


The problem is this language spreads FUD around DNS and then offers a “solution” with additional problems.


> 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.


Quad9 (https://www.quad9.net/) exists and is a 501(c)(3) DNS provider with a relatively reasonable privacy policy. It supports direct DNS resolving and has DOH servers available.

The problem is not so much the lack of available infrastructure but the lack of awareness of alternatives existing, so everyone ends up just using the known defaults (google or cloudflare mostly)


Brilliant. Tremendous this exists already. Someone get this to Mozilla!


I'm dubious. If someone asked me to run such a thing and offered to pay for it, I'd turn them down:

It's too easy to be compromised (via hackers, including the state funded kind) or ordered (e.g. via an administrative subpoena, NSL, or plain court order) and fail to deliver on the expected privacy. This false sense of security might even get people killed, when they think their activities are private when they really aren't.

You might get a strong selection effect for parties who are less principled, thoughtful, knowledgeable, or even outright less honest. Why should someone trust them more than cloudflare (who is already seeing a substantial portion of user traffic, because if you don't use them-- you get DDOS attacks and then mysteriously cloudflare sales contacting you).

The situation with Let's Encrypt is different-- the SSL CA process is already fairly insecure and bogus certs are already easily issued to any party that can MITM traffic to the target server. Even ignoring that ... Any one rogue CA which is trusted by browsers is enough. So there is little to no incentive to compromise Let's Encrypt.


If someone asked me to run such a thing and offered to pay for it, I would do so in a heartbeat (build, staff, and move on). You don't get progress without pragmatism and compromise. The benefits far outweigh the potential downside. You want people who care leading the charge.

We should endeavor to build something good enough today, so someone in the future can build something better on our shoulders.


Parent post already covered this in the original comment: the ISP can already see all IPs and often SNI. Basically they still see the host names. DoH is just adding an extra party to that chain.

I’m not taking sides here but the argument was made, and valid.


Even if you run your own DNS server, it's still making queries to other DNS servers. With regular DNS, this is not encrypted, of course. Almost nobody uses DNSSEC. So there's a lot of "trust" going on.


Firefox choosing reasonable defaults that improve security for regular users in practise given the state of the world at this time, seems reasonable to me.

By a similar token, you can opt-out of web pki by specifying all your own root CA's. But i hardly fault firefox for including sensible defaults.


99 % of users won’t touch default values, so it’s not a valid excuse.

I really have come to the conclusion that privacy is just a marketing feature for Mozilla. They e.g. also do nothing against data exfiltration by popular extensions although they have known that issue for years.

If they’re really serious about privacy they should have waited to implement DoH as an open standard and allow more DNS providers to support it. The browser could then simply see if your default DNS supports it and if yes switch to DoH.

This really smells like some kind of data deal between them and Cloudflare. This is not surprising because DNS data is really valuable and passive DNS monitoring is used for many purposes, e.g. security and marketing. Controlling this data gives you many interesting business opportunities, hence I can understand why Cloudflare and Google are after it.

It’s also revealing that they don’t enable this in the EU, because they rightfully fear that it’s not compliant.


> They e.g. also do nothing against data exfiltration by popular extensions although they have known that issue for years.

This kind of sentiment compels mozilla into becoming an apple-like gatekeeper to a walled garden because people conflate the trustworthiness of extension authors with mozilla's trustworthiness, which leads to less software freedom, a single point of failure and a less diverse ecosystem.


There simply should not be an API that allows exfiltrating the URL history of a user and then send it to a remote backend, at least not without making this very, very explicit to the user (which they currently do not).

You don't need to be a "gatekeeper to a walled garden", it's just necessary to have sensible APIs that respect users privacy. I think a browser that puts privacy as its primary feature should be able to do that.


This has nothing to do with an API. Any kind of extension that acts automatically (i.e. doesn't exclusively spring to life when clicking on an extension-specific button) will have to inspect the currently open tabs, page contents or network requests to decide whether it has to do its thing, which means it has access to this kind of information anyway and could exfiltrate it through standard web APIs (fetch/XHR).

This is not on mozilla, their current extension API surface already is much more limited than the old one (killing off some preexisting usecases in the process) and still has many ways to get this information.

It's kind of asking that git shouldn't have filesystem or network access.


Well, I was part of a team that proved that one of the most popular Firefox extensions (Web of Trust) stole and monetized user data, archiving every single URL a user opened and selling it to anyone who was willing to pay (the journalists I worked with even got a free sample containing the data of 3 million people). The extension was then banned for a few weeks before being reinstated, and happily continues to exfiltrate data from millions of users today. So pardon me if I have a slightly different view on this.

It is simply not true that building systems with privacy in mind is not possible. I can think of several ways to drastically improve the privacy of web extensions by providing audit logging or more fine-grained control over permissions.

Comparing end-user software like Firefox with developer tools like Git is also misleading, I find. There are countless studies that show most non-expert users don't know what is happening with their data and are not able to judge the risks they're taking when installing software like browser extensions.

Again, it's perfectly fine to build a product and not care much about user privacy, but if your main selling point is privacy this is different. It's just pointless to have the most advanced content blocking mechanisms when you allow browser extensions to circumvent them all.


> I can think of several ways to drastically improve the privacy of web extensions by providing audit logging or more fine-grained control over permissions.

You were talking about API surface though. Neither of these things are API surface in itself. They are after the fact, informing the user what it can do and what it did with those APIs.

> It's just pointless to have the most advanced content blocking mechanisms when you allow browser extensions to circumvent them all.

I don't think so. It's not pointless. It just means you need to trust more than mozilla, you ALSO need to trust the extensions, just like you need to trust many other things in your system. The error here is assuming that everything should be reducible or can be reduced to a single source of trust.

> There are countless studies that show most non-expert users don't know what is happening with their data and are not able to judge the risks they're taking when installing software like browser extensions.

Perhaps. But if you follow that argument then you end up with a locked-down system with little flexibility, which I was referring to as apple-style walled garden. Some people may value such a thing, but I wouldn't use or recommend firefox if it became something like that. I would flee in terror.

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.


Reducing the API surface is also a way to improve privacy, and I also see many ways in which you could do this, e.g. by not revealing the path (or at least the query part) of the URL to extensions. It's entirely doable and most extensions can work fine without knowing every single URL you open. Apple, Google & FB have all shown that this approach works to improve privacy (not that I want to endorse them here as privacy champions), so why should that not work in the browser?

You can also have an officially sanctioned distribution channel like an app store and still retain the ability to install any software you want. The problem as I see it is that Mozilla provides a free distribution and marketing platform for malicious actors via their extension store, and I think this is in violation of their principles (especially principle 4) because it nullifies most of the security features that their browser offers. It's like putting up a 10-feet reinforced concrete wall to protect your house from intruders and then leaving the backdoor wide open.

I really don't want to argue about this here, I just find they're not doing the right thing and I find it sad, because I care a lot about privacy and I think recently Mozilla just took some bad decisions regarding that.


> It's entirely doable and most extensions can work fine without knowing every single URL you open.

It's needed by: Greasemonkey (to determine whether to run a script), content blockers, password managers (to determine whether to fill in on that site) and any extension running web-standards compliant javascript against a page's DOM (i.e. any page-modifying extensions) as inherent part of standards-compliance

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.


It asks the user if they want to allow an extension to "Access Browsing History" [1]. That seems pretty explicit and self-explanatory to me.

[1] https://support.mozilla.org/en-US/kb/permission-request-mess...


No, it would be straightforward if they asked the user something like this:

"Is it ok that this extension sends every single URL you open to an untrusted third party for processing? Please note that URLs might contain sensitive data like access tokens or session information."

Even so, I don't think such an API should exist. And if you absolutely need to have something like this you should restrict it to domain information by default, cutting away the path.

I can understand that Google might not care much about this (Chrome itself is a data collection platform), but I really don't get why Mozilla is so lenient about it as well, as their main differentiator has been user privacy for years.


> Even so, I don't even think such an API should exist.

There is no "exfiltrate all my history" in the webextension APIs. What exists are two distinct and reasonable components.

A) accessing browsing history/current tabs/network requests¹. all things required for extensions to work B) ability to make generic network requets

Combining these two can be used to exfiltrate data. But that does not mean that any particular extension that has access to both will also exfiltrate private data. Thus a blanket warning would be overly broad and anything more targeted would require manual sourcecode inspection.

¹ Those require separate permissions, but for the purpose of the discussion they can all be used to harvest data


Wasn't there a big story on HN about how chrome had disabled the ability for plugins to see your URLs and how adblocker plugin makers where up in arms about it?


DoH is an open standard. DoH is also better for the 99% of users who don’t care about DNS resolvers and use their standard, shoddy and privacy invasive ISP provided one.


Just because something is open doesn't mean that it's ok to push it on users at will. DoH is highly controversial and not a standard, there are only a handful of players that push it for their own benefit.

Also, in most parts of the world people trust their local ISPs more than giant US corporations, you should not assume that everyone welcomes this centralization.


> in most parts of the world people trust their local ISPs more than giant US corporations

On what is this assertion based on?

I'm part of this world and I'm not a US citizen. I do not trust my local ISP, because they log and report traffic to local security agencies. It's bening at this point, tracking illegal activities, but they can connect whatever I do with my real name and address.

If I were to guess, in most parts of this world people don't have freedom of speech and fear repercussions from their government for their online activity.

The profiling that US companies do for serving better ads is essentially a first world problem, and a pretty irrelevant one for most people.

Also if we had such deep mistrust in US companies, first of all we shouldn't be using devices and operating systems built by US companies.


My ISP has to obey the rules of my government, and it is not allowed to sell my data. It's in my country, with my regulatory bodies and close enough that I (or a group of people like me) can sue them, if they start doing bad things.

What the hell am I supposed to do again cloudflare?


> I really have come to the conclusion that privacy is just a marketing feature for Mozilla. They e.gg. also do nothing against data exfiltration by popular extensions although they have known that issue for years.

I thought about this recently, and the move to HTTPS-Everywhere is the biggest issue here. In the old days, you could have something like the @guard firewall on Windows, which could examine all outgoing HTTP connections, and block ads and malware by examining not just the hostname, but also the URI of each request. This meant it was separate from the browser, worked with all browsers, and didn't break every time your browser is updated. It's pretty easy to write a similar tool on UNIX to act as a proxy, too, and make it network-wide through your OSS router.

Nowdays, because it's all encrypted with certificate authorities and all, it's much more problematic to block ads and malware, because then you'd also have to intercept HTTPS, and manage certificate authorities and such. I guess it's still doable in principle, just more involved, with a considerably worse UI? Has anyone tried anything like that in the HTTPS world, do any solutions exist as FLOSS at all?


Intercepting HTTPS is possible, but not easy. It just requires configuring your browser to use a known key pair for client authentication so that you can MITM yourself from a local or network proxy.

On the consideration of trade-offs, I think HTTPS-Everywhere is completely worth it. It may be more complex to intercept your own traffic, but since you are in control of one of the endpoints and the ISPs (which in the US are openly trying to market your browsing data) are not, I still consider it an overall win for privacy.


HTTPS intercepting proxies ("middle boxes") are commonly deployed in the corporate world. Firefox-- and internet protocols themselves-- makes many concessions to avoid gratuitously breaking these things.

For free software, squid ssl-bump works, though is something of a pain to configure!


> makes many concessions to avoid gratuitously breaking these things.

Or to look at it from another perspective, if you do this then in configuring the browser to accept it (typically, adding a private CA as trusted) you agree that you broke the browser's provided security promises and are happy without them.

In principle this can be safe if the middlebox you use has its finger on the pulse (usually dubious) and you're applying security updates to the middlebox as you would a browser or other outward facing software. So far I've never seen one I'd trust.


> Cloudflare is just one of the initial providers and they indicate that they are adding more. Also, I'm assuming you can add your own custom provider based on the screenshot in the article. You can just disable the feature as well.

Or go for https://firejaildns.wordpress.com/ - Linux workstation DoH proxy, more than 60 DoH providers. When you start, the proxy chooses one at random. You can also set the servers in Firefox.


If you just want a DNSCrypt and DoH proxy for Windows you can use Simple DNSCrypt. It also has over 60 DNS providers included and has data on which ones use filters to block requests, which ones log requests, and which ones support DNSSEC. How much you trust this data is up to you.

https://www.simplednscrypt.org/


> You can just disable the feature as well

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.


> Firefox DoH is snake oil, plain and simple...

Correct me if I'm wrong, but the concern I have about browser-controlled DoH is that it seems like it could make it harder for a tech-savvy user to assert control over their own network. IIRC, most network-level ad-blocking operates at the DNS level. I've also personally blocked telemetry by setting my router's DNS proxy to resolve certain telemetry servers to 0.0.0.0. It's my understanding that DoH would bypass that. Couple that with Google's planned neutering of Chrome's ad-blocking API, and it seems like it will become increasingly hard for end-users to avoid ads.

And the fact that DoH uses HTTP seems like it would make it impractical to block as a protocol.

I think I would have preferred an encrypted DNS protocol that ran on its own port, at least.


For existing configurations, it makes it a bit trickier to implement. If you ad the aforementioned rules to your DNS and/or IP block list, then Firefox will default back to using the system configured DNS.

But DoH is not targeting ad-blocking specifically, but rather intermediaries that are outside of the local network. There is evidence of ISPs injecting traffic (Comcast/Xfinity) or selling user traffic (AT&T) and this was designed to close one of the last gaps for a fully encrypted flow.

It's possible to setup a DoH server for your local network's DNS resolver, so that all of your traffic leaves your network encrypted, even if not encrypted on your local network.


Firefox tries to recognize some personalized DNS servers and prefer them to DoH in cases where it finds them. The FAQ here suggests that work is ongoing and they are hoping tech-savvy DNS alternatives used for things like parental controls and ad blocking meet them somewhere in the middle in terms of making it easier to Firefox to auto-disable DoH when a user has explicitly opted in to more power user configurations.

Similarly related is the general idea is that if you have the tech savvyness to setup a PiHole in the first place, you should be able to find the Firefox settings on your devices to disable DoH, and Firefox isn't hiding those settings, they are just trying to make a default that is better for more people (the folks that aren't tech savvy and have a different threat model than the power user with a PiHole or similar).


> you should be able to find the Firefox settings on your devices to disable DoH,

You should be able to find a buried config option to regain your privacy is _not_ a position that we should consider acceptable!

There are serious logistical challenges keeping the option off even at a household level.

At the moment it isn't difficult to block at the network level, but presumably they'll start evading those blocks eventually or otherwise the claim that this is intended to prevent monitoring by ISPs will seem pretty hollow.


Mozilla seems to have made it clear that where DoH is on by default the config option won't be "buried", particularly because out of the box multiple options will be provided (both Cloudflare and NextDNS). That you see it as "regain" says we probably have different threat models/assessments here, I'm not sure I can help you much further with the paranoia associated with your current threat model.


Paranoia? What exactly is paranoid about being concerned about the browser sending all firefox users traffic for an entire nation to a single party which has the technical ability to monitor all this traffic and under which current norms have essentially zero protection under the law?

Surveillance at large providers is an unambiguous fact, centralizing all user's traffic at one makes it tremendously easier.

The majority of US broadband users are on comcast, which as reported-- in spite of stinking in many respects has made similar public commitments to cloudflare to not monetize this data.

I think you likely have it reversed which threat model is more fringe and which is more concerning.


> At the moment it isn't difficult to block at the network level, but presumably they'll start evading those blocks eventually or otherwise the claim that this is intended to prevent monitoring by ISPs will seem pretty hollow.

Have you considered using a different browser? One that aligns more with your values?


If you use the nextdns DoH provider in Firefox you can actually configure your own adblocking domains even when you're moving around across networks. Just FYI


> If you use the nextdns DoH provider in Firefox you can actually configure your own adblocking domains even when you're moving around across networks.

Uh. Doesn't this prove that Firefox's DOH implementation is sending strong per-user identifying information to the server?


That’s what nextDNS offers (basically pihole in the cloud). And that only works by hitting a specific subdomain or endpoint on nextdns.io.

If you’re hitting cloudflare, it’s just hitting the regular endpoint so no user identifying information.


Ah. Thanks! Makes sense.


If you configure a personal NextDNS URL as the DoH provider then unsurprisingly NextDNS will know that URL was used, and personalise things accordingly.

If you use Firefox's defaults but pick NextDNS from the list, you don't get personalisation as NextDNS has no idea who you are.

A nice thing about DoH here: For DNS over TLS NextDNS has to hide the configuration ID in the hostname, which as a result is revealed in SNI, but for DoH they can put it in the path and so it is encrypted like everything else.


> ...for DoH they can put it in the path and so it is encrypted like everything else.

Wait: You mean to say URLs are encrypted? I thought not. There must be a reason why GET requests aren't used for secret-sharing, for instance, as opposed to POST. What am I missing?


An HTTPS URL has several parts, let's look at them in turn from left to right of a URL https://userinfo@someserver.example:1234/foo/search?term=goo...

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.


Thanks for the detailed reply. Appreciate it.


SNI is not a good argument, there is work being done to encrypt that as well in TLS 1.3 with Encrypted SNI[1].

[1] https://blog.cloudflare.com/encrypted-sni/


ESNI only helps if you're fronting through things like cloudflare, again putting more eggs and information into a single basket and making them a more valuable target for TLAs.


True, centralization is a downside. But the alternative is having no privacy from government agencies. Even if you somehow believe your ISP won't be subject to these hypothetical interception orders that CloudFlare would be subject to (why?), there are plenty of points to tap in between your ISP and the website you're visiting.


There's a tcp/443 connection to 208.80.153.224, what site could it be?

$ 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

Ref: https://rdap.arin.net/registry/ip/208.80.152.0


  mike@blob:~$ host 208.80.153.224
  224.153.80.208.in-addr.arpa domain name pointer text-lb.codfw.wikimedia.org.

  mike@blob:~$ openssl s_client -connect 208.80.153.224:443 2>&1 | openssl x509 -text|grep Subject:
        Subject: C = US, ST = California, L = San Francisco, O = "Wikimedia Foundation, Inc.", CN = *.wikipedia.org
Yeah, our ISPs are going to be totally in the dark thanks to DoH. /s


> mike@blob:~$ host 208.80.153.224 224.153.80.208.in-addr.arpa domain name pointer text-lb.codfw.wikimedia.org. mike@blob:~$ openssl s_client -connect 208.80.153.224:443 2>&1 | openssl x509 -text|grep Subject: Subject: C = US, ST = California, L = San Francisco, O = "Wikimedia Foundation, Inc.", CN = *.wikipedia.org Yeah, our ISPs are going to be totally in the dark thanks to DoH. /s

minjiexin.com resolves to the same IP. So, you see an HTTPS connection to 208.80.153.224, what's the user doing?


In this particular case, the ISPs db entry could simply be "customer visited either wikipedia.org or minjiexin.com", and that would be practically as good as before DoH.

Or the ISPs database could simply be of IP addresses connected to, and the purchaser of that database could apply identification based on which other IPs were connected to around a similar time.

If it's your argument that mapping IPs to "websites visited" is not 100% accurate, then of course you're correct... So what we need to do is figure out how accurate it is. Because if the answer to that question is 95%, then the whole value proposition of DoH flys out of the window. Why massively centralise DNS to just make a tiny dent in the problem?

If the answer to that question is 5% rather than 95%, then I guess that would mean we've centralised the web so far already behind gatekeepers like Cloudflare+Google+AWS+Microsoft, that it doesn't really matter if we go and centralise DNS for web usage in the same way, as the web is already fucked.


> ... what's the user doing?

$ 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.


It is since ESNI is only a draft right now. Implementations matter.


> It sends all the users DNS queries to Cloudflare, adding a new party

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"


> who are legally bound to respect your 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.


> Look at what has happened with misbehaving CAs.

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).


"This makes no sense. your ISP cannot see that you are visiting facebook"

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
Or:

  openssl s_client -connect 185.60.216.35:443 2>&1 | openssl x509 -text|grep Subject:
Or one of a miriad of other ways to get a hint about the hostname of the service you're connecting to, at which point they can automatically do forward DNS lookups to confirm what matches.

DoH only adds to the number of organisations that can see your web traffic. It does not reduce it, or shift it to a more trustworthy organisation. It just adds more leaks.

DoH/ESNI don't stop your ISPs knowing exactly what sites you're visiting unless we centralise HTTP behind a handful of benevolant gateways the same way Mozilla is doing with DNS.

Fuck that.


My ISP is legally bound to respect my privacy. I have regulatory bodies literally 10 minutes away, that can deal with tham, and a court system where I (and many more like me) can sue the ISP if they do something bad.

What can I, citizen of small EU country, with an en_US firefox, do against cloudflare?


It's a balance. Do you want your plaintext DNS request sent to starbucks or your local unsecured public wifi, or do you want it sent encrypted to your DoH server of choice?


I want to not see further centralization of Core Internet Infrastructure to CloudFlare


I can use a VPN when browsing on those kind of networks.


That's fine for more technical users who are aware of how to mitigate this kind of issue, but then those same more technical users will also likely know how to disable DoH.

For the majority of users who may not understand the risks around plain text DNS, there are advantages to it being encrypted.


"Good" VPNs also aren't usually/ever? free.


You can operate one on your home router, which can be negative-cost if you're also saving the rent on the ISP hardware.


Well, sure.

However, my comment was within the context of the parent's, which was talking about how this feature is beneficial to non-technical users; some of which may not be able to afford to pay for a VPN that (probably doesn't ...) MITM or log traffic.


Ideally this would be a standard component of home routers, especially some easy wireguard QR-code setup. But yes, until this happens it's something for more tech-savy users.


> will also likely know how to disable DoH.

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.


I've already had a lot of issues with embedded devices that have hardcoded resolution against 1.1.1.1 not working correctly against my local names.


This has always been a poor argument. Especially for FF which is mainly used by Technical people

Chrome a d IE are used by people that do not understand the risks around DNS

I use FF because I am / was tried of IE and Chrome telling me how I should use thier software, now Mozilla is making the same moronic choices for me instead of empowering users

DoH should be Opt-In, not Opt-Out


You using FFox because you're technical, doesn't mean a majority of FFox's user base is technical.

Technical users (like yourself) can just easily disable DoH, problem, for you, solved :)


> Firefox DoH is snake oil, plain and simple.

This is not an accurate statement, for the commonly accepted definition of "snake oil".

Your privacy concerns are, from an angle, legitimate (although encrypted protocols, as a general rule, are more private than plaintext protocols), but this is a bit over the top.

TFA also mentions that they are partnering with NextDNS, so your claims about centralization are on shaky ground, too. I personally use NextDNS on my whole LAN. They're great!


I think his point is about the default behavior pointing to Cloudflare. Unless the user changes the DNS provider setting, everyone will be on Cloudflare. With that said, I think this is pretty over-the-top. Part of the reason Cloudflare is the default (and NextDNS is an option) is because they are abiding by Mozilla's Trusted Recursive Resolver policy: https://wiki.mozilla.org/Security/DOH-resolver-policy

The only way Cloudflare itself can cause users a privacy issue through the use of its DNS service is by lying to them. They have already agreed not to sell or grant the data to any third party or use it for advertising, etc.

The other concern nullc has is that hackers will infiltrate Cloudflare because it will now contain data on all US Firefox users' DNS queries unless those users change default settings. OK. I guess. However, I will say that I trust Cloudflare a whole heckuva lot more than I trust Comcast, Charter, AT&T, Verizon, etc. to be practicing good security. There are also probably more people on the mega ISPs than there are Firefox users, and many DNS queries these days originate from platforms that aren't even PCs (such as home theater streaming sticks) which will still be pinging default DHCP-received DNS providers. If anything, I see this decentralizing DNS request data.


The mozilla policy allows cloudflare to permanently store and exploit per-domain-name but not per user data. So even going by the letter of the policy and considering cloudflare alone there is still a privacy loss.

Moreover, the current legal standard in the US is that users have no expectation of privacy for data that third parties have stored about their activity. As a result there is potentially limited to no due process protection for user information in this scheme. Cloudflare could be required to turn the information over via an administrative subpoena and without the oversight of even a court or any ability for the impacted users to learn about or challenge the surveillance.

> I will say that I trust Cloudflare a whole heckuva lot more than I trust Comcast, Charter, AT&T, Verizon, etc. to be practicing good security

Than any one of them? I could imagine that. Than all? Cloudflare is a much bigger target.

> I see this decentralizing DNS request data.

Could you elaborate on that? I see this as massively centralizing DNS request data (onto cloudflare) and this change is the most problematic part of the whole thing.


> Could you elaborate on that? I see this as massively centralizing DNS request data (onto cloudflare) and this change is the most problematic part of the whole thing.

1. Firefox's browser marketshare is around 10%. This moves roughly 10% of DNS requests off ISP DNS providers to Cloudflare. Each of the major ISPs controls more than 10% of the broadband market.

2. It's only impacting Firefox browsers. To get an overall picture of the DNS request landscape and privacy, one has to include every DNS request made by a computing device that doesn't go through a Firefox browser. Even for Firefox users, the vast majority of their DNS requests probably don't come from web browsing in Firefox.

3. Firefox also makes it very easy to switch DNS providers to DHCP default or NextDNS. Of course users can still use custom options as well. Many Firefox users are probably savvy enough to exercise these options.

Based on what I've laid out above, I would guess that this change by Firefox might be redirecting a low-single-digits percent (very possibly less than 1%) of DNS request traffic to Cloudflare vs. where it went previously. That sounds like decentralization to me.


My concern about DoH is that it gives marketers and other spies the ability to do DNS lookups while evading my defenses -- regardless of whether or not I'm allowing my browser or other software to use DoH.

The only solution to the problem that I could come up with was to install a MITM proxy in my LAN so that I can detect and filter any sneaky DNS lookups.

I'm still very peeved that Mozilla has forced me to take such measures.


How does DoH allow marketers to do anything they couldn't have done before by just hardcoding their own DNS server?

It might make it harder to block queries by deep packet inspection, but do you actually do that on your network right now?


Marketers using hardcoded private servers are the easiest thing to defend against: just block those servers. That fact is one of the big reasons why marketers and other spies don't do that -- they use DNS lookups to find the mother ship.

However, now marketers can use DoH, combined with public servers that would cause disruption to block, to be able to engage in lookups without a means of detecting or blocking them short of doing a MITM setup.

> do you actually do that on your network right now?

Yes, I installed it months ago to defend myself against DoH. I MITM all HTTPS connections, detect DoH lookups, and block them.


Safer protocols don't care who or what they protect. Even if browsers didn't use DoH, other devices could. And any protocol Mozilla can use to protect their users will also work for other devices.

I don't think it makes sense to bemoan the newfound existence of safer infrastructure for everyone just because devices you don't like can also use that infrastructure.


> Even if browsers didn't use DoH, other devices could.

Precisely so.

> I don't think it makes sense to bemoan the newfound existence of safer infrastructure for everyone just because devices you don't like can also use that infrastructure.

I'm not. First, I don't think this is actually a "safer infrastructure" compared with other DNS encryption schemes, because it opens a new hole.

Second, this isn't about "devices I don't like" using an infrastructure. This is about software and websites being able to bypass a layer of my defenses.


> First, I don't think this is actually a "safer infrastructure" compared with other DNS encryption schemes, because it opens a new hole.

Browsers are completely correct to treat the network as hostile in their default configurations, unless explicitly configured to trust something. More prevalent end-to-end encryption is a good thing. And DoH makes it easier to get encrypted DNS requests through without having them blocked by hostile networks who want to intercept those DNS requests.

If an encrypted DNS scheme is blockable by you, it's blockable by an ISP. There will not be an uproar about it, any more than there's currently an uproar about ISP's selling DNS-based browsing information about their users. It will simply fail.


> More prevalent end-to-end encryption is a good thing.

I agree -- I am not arguing against more prevalent e2e crypto at all.

> If an encrypted DNS scheme is blockable by you, it's blockable by an ISP.

Perhaps, but it's also possible (unless you're using DoH) to evade those blocks without a great deal of difficulty.

I'm not arguing with anything you've said here, really. I'm just pointing out that the way that DoH works means that there is a security hole that makes it very easy for marketers and other spies to evade your protections against them.

So yes, DoH brings some security gains. But at the same time, it also brings some security losses. Whether that tradeoff is good for you should be a decision you can make -- but again, due to the way DoH works, you no longer have that choice available to you without going to extreme measures like I have.


If you are going to that level of effort then why not just block the IPs of the marketing servers themselves?


That is an ineffective approach for a number of reasons. This is essentially a blacklist approach, and blacklist approaches are very weak.

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.)


Don't those disadvantages apply just the same to your blacklisting of marketers' DNS servers?


Indeed they do, which is why that's not a sufficient defense all by itself.

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.


I think maybe you misunderstood what I'm asking.

Why couldn't such a spy just hardcode their own DNS server IP address, rather than using your network provided DNS server? If the answer is that you'll blacklist the spy's DNS servers, then how is that any different than the situation with DoH?

DoH isn't adding any value for the spy unless you are doing deep packet inspection of any packet that contains DNS data.


> If the answer is that you'll blacklist the spy's DNS servers, then how is that any different than the situation with DoH?

There are two differences that DoH brings up about this.

The first is that because mainstream DNS providers are beginning to support DoH, there is no need for anyone to set up their own private DNS server. In fact, they wouldn't want to -- much better to use a real one that can't be blocked without causing unacceptable collateral damage.

The second is that DoH hides the entire interaction from me (unless I do what I did -- implement a MITM proxy to decrypt all HTTPS traffic).

> DoH isn't adding any value for the spy unless you are doing deep packet inspection of any packet that contains DNS data.

Sure it is. It effectively disables a layer of defenses from the spies.


> 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.

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?


Unfortunately it's not so easy to black hole `use-application-dns.net` for parental control. (people don't run their own DNS server).


FWIW, I've found that running a local unbound server with moderately aggressive caching makes a visible improvement in browsing speed. For us technical folks, it worth doing for the speed up even without getting into the configurability/privacy implications.


I have had the exact same experience. It's one of the first things I verify whenever I connect from a new location – are my queries being resolved by my local unbound or not.


> It sends all the users DNS queries to Cloudflare

I wonder how much Cloudflare paid for this 'privilege' of being the default DNS provider.


Mozilla claims that Cloudflare is not paying them, and claims that they have a contract with cloudflare which prohibits them from selling the data.

I don't think that this improves the situation substantially. The history of internet privacy failures is full of empty and unrealized promises, and no amount of contracts or promises can trump a court order or a NSL. "Has no ability to collect" is the gold standard, and the only level of protection that guards against compromise and blanket state surveillance activities.

AFAIK they also have never published the contract itself, though doing so wouldn't address the above points.

Edit: After carefully reading the cloudflare privacy statement ( https://developers.cloudflare.com/1.1.1.1/commitment-to-priv... ) I believe it unambiguously states they will collect "aggregate data" such as how much traffic each specific domain is receiving and use it for their own 'development' purposes. To me this seems extraordinarily valuable by itself, quite a windfall.


ISPs can and do sell your information, and can also be served a warrant or NSL. Cloudflare, by contract, is prohibited from doing the former, which is a net improvement even if they're still subject to the latter.

It's an incremental improvement, but a positive one.

I would certainly love to see an even better protocol for Internet name resolution that prevents anyone from having name-lookup information, but in the meantime, DoH seems like a huge step forward in ensuring that no unencrypted traffic is visible to the ISP or local network.


> ISPs can and do sell your information

Not in my country, they'll be massively fined if they're caught doing that.


Mozilla is only enabling DoH through Cloudflare by default in the US.


Your ISP, however, is not prevented from collecting and selling your data by DoH. So the addition of default DoH in cloudflare adds an extra party that can intercept your traffic but does not remove any.

> DoH seems like a huge step forward in ensuring that no unencrypted traffic is visible to the ISP or local network

It does not do this.


DNS traffic is a much richer and more valuable resource than a simple list of IP sessions.

Yes, of course your ISP can see who you're connecting to and sell that, but denying them (and anyone else) the ability to collect all DNS traffic is better than not denying that.


DoH is significantly richer than DNS itself because of session reuse.

DNS is cached, other than potential ambiguity related to shared hosts (which can be resolved by looking at SNI)-- I'm failing to see how DNS is richer than the traffic itself. Less costly to monitor? Sure.


Agreed. Unless that contract includes heavy penalties for selling and/or losing that data, its toothless nonsense. The fact that the contract hasn't been published is also problematic. If everything is above board, why hide?


To be fair, publishing contracts like that isn't a standard practice. That alone is a sufficient explanation. It still would be better if it were.


Mozilla isn't a standard company and this isn't a standard situation.


>Mozilla claims that Cloudflare is not paying them, and claims that they have a contract with cloudflare which prohibits them from selling the data.

As you said, this does not improve the situation. Mozilla can't even verify it.

Also it could be a reverse data selling situation like with Google: They don't sell the data, companies pay money to Google to display ads to the users. Since they have so much data, they can target specific groups more easily. Data doesn't even need to leave Google for that to work.


This seems unnecessarily alarmist. DNS over HTTP doesn't protect against state-level legally-mandated surveillance because it's not designed to protect against state-level legally-mandated surveillance. There are no solutions to the problem you posit that don't involve SOME kind of trusted name authority somewhere that is, effectively by argumentative fiat (i.e. not really) "out of the reach" of whatever government it is that you don't trust. That's not something you're going to find a technical solution for.

The real problem addressed by DoH is the routine surveillance and hijacking of "presumptively public" names by local network operators. And it works comparatively well for that.


By "comparatively well" you mean defeated in bulk by deploying sampled netflow with a couple lines of router configuration-- which almost all major ISPs already have deployed for monitoring purposes.


> But there is no guarantee that these mitigations will continue to work.

This is the biggest problem. It used to be that Firefox was on your side, but now it's turning into the we-know-better-than-our-users Chrome, where they don't even feel like guaranteeing that disabling this malicious and unwarranted service today will continue to leave it disabled tomorrow.


If you can run iptable commands or run bind you can certainly go to the Firefox options and disable/change DoH there?


Looks like people are also working on block lists that work with pfBlockerNG and pfSense, ex:

https://old.reddit.com/r/pfBlockerNG/comments/d3p1gf/doh_ser...


I don't care if my ISP knows I visit reddit.com.

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).


> I'm already protected by TLS for the latter.

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?


I use cloud nine because I dont' like CF: https://dns9.quad9.net/dns-query


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: