Mozilla’s DNS over HTTPs(blog.mozilla.org)
blog.mozilla.org
Mozilla’s DNS over HTTPs
https://blog.mozilla.org/netpolicy/2020/02/25/the-facts-mozillas-dns-over-https-doh/
775 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.
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....
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.
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
--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.
> 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.
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/
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.)
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?
Why?
some prior discussion for context -- https://news.ycombinator.com/item?id=19828317
They have a beef with Cloudflare over Cloudflare removing EDNS Client Subnet for privacy reasons.
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?
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?
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...
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.
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.
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.
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.
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.
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.
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.
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
These are separate features and should be decoupled accordingly.
https://bugzilla.mozilla.org/show_bug.cgi?id=1500289
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.
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.
[deleted]
Peepootoler(1)
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.]
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.
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 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.
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.
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.
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 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.
DoH is first of all a protocol. If you run your own DNS resolver at home, surely you'll be able to run your own DoH server too.
Also your requests will no longer be sent in clear text, which means that a Wifi administrator at your local coffee shop won't be able to see your queries and responses, which with the regular DNS protocol are in cleartext, in which case your home DNS server does not help — unless you're on your own network in full control of your router, or run your own VPN, communications with your home DNS resolver are just as vulnerable.
The value of something like DoH is clear, regardless of the motivation that Cloudflare and Google have for providing such a service for free.
---
Speaking of which, accessing pirated content is not the only case I worry about — another problem I have with my ISP is that they serve me a 404 Not Found page filled with ads on domains that aren't available. This is in an EU country.
Also back when HTTPS wasn't forced on Google, the searches were logged and people were automatically flagged for problematic queries and then potentially monitored for years. One of the topics that triggered automatic flagging was child sexual abuse — I know because I helped a local campaign, building an awareness website, etc, only to be informed of such practices by an acquaintance working for our internal security agency.
And while today this may happen for legitimate reasons, tomorrow it might happen for people criticizing the government. Look no further than countries like Turkey or Hungary.
Personally, coming from communism, I fear the nanny state more than I fear big companies from other countries.
> Personally, coming from communism, I fear the nanny state more than I fear big companies from other countries.
I am from Slovenia and I know exactly what you mean, and agree 100% with that.
I just think that in the end POE is worse, since I think it will result in concentration of something that was widespread (plenty of small ISP's and providers), into few bigger and easier to backdoor providers. So it will be easier to monitor then before. And I don't think think that western democracies and "democracies" will just throw in their towel.
I trust Cloudlfare and Google less than I trust my ISP, if nothing else their budget (and competence, and reach) is much lower(isp's).
I mean gmail and outlook are much more competently run than most ISP's and businesses ran their mail servers. I am afraid something similar can happen here.
> DoH is first of all a protocol. If you run your own DNS resolver at home, surely you'll be able to run your own DoH server too.
Packets never leave local network. The advantage of DoH is that it's over https, so if you don't control your firewall you can still use it. But if you control your own network, DoH is not that useful, since you still have to support old DNS for all the applications and devices that don't support DOH. If someone can listen on your LAN you have bigger problems than someone being able to intercept your DNS queries. Not saying there are no advantages, it just isn't a priority.
I 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.
[deleted]
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?
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.
> 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!
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.
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
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
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.
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.
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)
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.
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 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.
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.
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.
> 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.
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.
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.
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.
[deleted]
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.
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.
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.)
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.
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.
> 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.
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.
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.
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.
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)
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.
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.
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.
> 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".
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.
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.
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.
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...)
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.
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-...
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...
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.
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.
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.
> 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. 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 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.
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.
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.
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.
Chrome is bootable already. ChromeOS. :P
You can definitely do DNS over HTTPS/TLS for everything if you run your own DNS server, either locally or somewhere on your network. I do this, and it works great, both methods have their own advantages and disadvantages of course.
> We continue to explore enabling DoH in other regions, and are working to add more providers as trusted resolvers to our program. DoH is just one of the many privacy protections you can expect to see from us in 2020.
Cloudflare is just one of the initial providers and they indicate that they are adding more. Also, I'm assuming you can add your own custom provider based on the screenshot in the article. You can just disable the feature as well.
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.
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.
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).
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.
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
http://clerk.house.gov/evs/2017/roll202.xml
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
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.
* 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.
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.
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".
> 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...
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.
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.
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?)
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.
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.
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
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.
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/
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?
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).
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...
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.
> 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.
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.
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.
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.
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)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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'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...
[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.
"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
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.
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.
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?
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?
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.
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!
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.
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.
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/
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.
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.
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.
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).
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.
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.
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?
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?
Uh. Doesn't this prove that Firefox's DOH implementation is sending strong per-user identifying information to the server?
If you configure a personal NextDNS URL as the DoH provider then unsurprisingly NextDNS will know that URL was used, and personalise things accordingly.
If you use Firefox's defaults but pick NextDNS from the list, you don't get personalisation as NextDNS has no idea who you are.
A nice thing about DoH here: For DNS over TLS NextDNS has to hide the configuration ID in the hostname, which as a result is revealed in SNI, but for DoH they can put it in the path and so it is encrypted like everything else.
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?
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://[email protected]: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.
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/
[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
$ 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
> 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?
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.
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.
$ 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"
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.
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).
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:
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.
There are many massive databases of ip to hostname mappings which can be trivially queried by an ISP to see what service you're connecting to.
Or if they see you connecting to 185.60.216.35, they can just:
curl http://185.60.216.35 -v 2>&1|grep Location
openssl s_client -connect 185.60.216.35:443 2>&1 | openssl x509 -text|grep Subject:
DoH only adds to the number of organisations that can see your web traffic. It does not reduce it, or shift it to a more trustworthy organisation. It just adds more leaks.
DoH/ESNI don't stop your ISPs knowing exactly what sites you're visiting unless we centralise HTTP behind a handful of benevolant gateways the same way Mozilla is doing with DNS.
Fuck that.
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?
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.
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.
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.
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
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 :)
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!
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 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.
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.
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.
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?
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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?
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.
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.
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.
It's an incremental improvement, but a positive one.
I would certainly love to see an even better protocol for Internet name resolution that prevents anyone from having name-lookup information, but in the meantime, DoH seems like a huge step forward in ensuring that no unencrypted traffic is visible to the ISP or local network.
Your ISP, however, is not prevented from collecting and selling your data by DoH. So the addition of default DoH in cloudflare adds an extra party that can intercept your traffic but does not remove any.
> DoH seems like a huge step forward in ensuring that no unencrypted traffic is visible to the ISP or local network
It does not do this.
> 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.
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.
DNS is cached, other than potential ambiguity related to shared hosts (which can be resolved by looking at SNI)-- I'm failing to see how DNS is richer than the traffic itself. Less costly to monitor? Sure.
Agreed. Unless that contract includes heavy penalties for selling and/or losing that data, its toothless nonsense. The fact that the contract hasn't been published is also problematic. If everything is above board, why hide?
>Mozilla claims that Cloudflare is not paying them, and claims that they have a contract with cloudflare which prohibits them from selling the data.
As you said, this does not improve the situation. Mozilla can't even verify it.
Also it could be a reverse data selling situation like with Google: They don't sell the data, companies pay money to Google to display ads to the users. Since they have so much data, they can target specific groups more easily. Data doesn't even need to leave Google for that to work.
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.
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.
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...
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 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?
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
I think this is generally a good thing. Two questions I've often seen surface on HN though weren't answered:
1. Isn't this better implemented at the OS level?
2. Isn't centralisation to two DoH providers more centralised than five large ISPs?
Others are probably better suited to answer, but the answers I can think of:
1. Yes, but it is not, so this solution is second-best. If Operating Systems decide to tackle this problem at some point in the future, Firefox can always be changed again to use that.
2. Given that Firefox doesn't own the full market, the net result is indeed less centralisation: five ISPs that handle traffic by other browsers, and two DoH providers that handle Firefox's. That said, the main factor here is that the track record of ISPs in the US is abysmal, whereas the current (and hopefully potential future other ones) DoH providers have committed to far stronger privacy protections.
1. Isn't this better implemented at the OS level?
2. Isn't centralisation to two DoH providers more centralised than five large ISPs?
Others are probably better suited to answer, but the answers I can think of:
1. Yes, but it is not, so this solution is second-best. If Operating Systems decide to tackle this problem at some point in the future, Firefox can always be changed again to use that.
2. Given that Firefox doesn't own the full market, the net result is indeed less centralisation: five ISPs that handle traffic by other browsers, and two DoH providers that handle Firefox's. That said, the main factor here is that the track record of ISPs in the US is abysmal, whereas the current (and hopefully potential future other ones) DoH providers have committed to far stronger privacy protections.
For 1, you're spot on.
For 2, the one thing that's missing from here is that we _know_ many ISPs are selling your data. I'm really uncertain why people are so determined to villify Cloudflare - who don't really stand to gain that much more useful info about you from this than they already have - and give a totally clear pass to their ISP despite years of proven bad behaviour. Yeah this (by default) uses CF's DoH service - note that you can change this if you want - but in my view that's strictly better than continuing to allow your ISP to to sell your browsing history. In other words - a bit of by-default centralisation is in my view an acceptable price to pay for the increases in privacy and security (especially as it's trivial to switch away from CF if they behave badly).
For 2, the one thing that's missing from here is that we _know_ many ISPs are selling your data. I'm really uncertain why people are so determined to villify Cloudflare - who don't really stand to gain that much more useful info about you from this than they already have - and give a totally clear pass to their ISP despite years of proven bad behaviour. Yeah this (by default) uses CF's DoH service - note that you can change this if you want - but in my view that's strictly better than continuing to allow your ISP to to sell your browsing history. In other words - a bit of by-default centralisation is in my view an acceptable price to pay for the increases in privacy and security (especially as it's trivial to switch away from CF if they behave badly).
A good solution would be to do DoH upgrade to their existing provider if the user already has DNS set to a non-ISP resolver (eg. Google, openDNS), only using CF as a default for ISP dns. That or racing multiple DoH providers for the first few queries to choose the fastest one for the user.
Internet gateways commonly give out the gateway's IP address as the DNS and then forward requests upstream from there. How does the application know which DNS the gateway is configured to use?
In [currently only] Chrome, it doesn't upgrade if the DNS advertised is the router. This proposed Firefox system then would default to CF [or default to the fastest one].
>who don't really stand to gain that much more useful info about you from this than they already have
that is absolutely untrue. Today they only have data for websites already using CloudFlare Services.
DoH they can info on ALL websites users for FF visit. and while their "contract" with mozilla requires they "anonymize" the data, they are admitted to collecting aggregate data which is VERY valuable in itself, plus I never trust companies when they say they will "anonymize" the data
Further I have not see what if any penalties are imposed on cloudfare for any violations of the "contract" they have with Mozilla, if there are no penalties then the contract is pointless and not an assurance of anything
As to why people villify Cloudflare, it is what CloudFlare represents that is a problem for people like me. The Internet is best serviced by decentralization. in the last 10 to 20 years we have seen and continue to see MASSIVE centralization of core infrastructure.
FF move here represents another step on that path. CloudFare already has too much of the net behind their infrastructure.
They are an inherit threat to the free and open web
that is absolutely untrue. Today they only have data for websites already using CloudFlare Services.
DoH they can info on ALL websites users for FF visit. and while their "contract" with mozilla requires they "anonymize" the data, they are admitted to collecting aggregate data which is VERY valuable in itself, plus I never trust companies when they say they will "anonymize" the data
Further I have not see what if any penalties are imposed on cloudfare for any violations of the "contract" they have with Mozilla, if there are no penalties then the contract is pointless and not an assurance of anything
As to why people villify Cloudflare, it is what CloudFlare represents that is a problem for people like me. The Internet is best serviced by decentralization. in the last 10 to 20 years we have seen and continue to see MASSIVE centralization of core infrastructure.
FF move here represents another step on that path. CloudFare already has too much of the net behind their infrastructure.
They are an inherit threat to the free and open web
FWIW, wrt 1: you can use dnscrypt and a bitbar plugin to have this at the OS level on Mac. It’s a faff to setup but once it works it really does work.
https://www.dnscrypt.org/
Optional for menu icon:
https://getbitbar.com/ and https://github.com/jedisct1/bitbar-dnscrypt-proxy-switcher
https://www.dnscrypt.org/
Optional for menu icon:
https://getbitbar.com/ and https://github.com/jedisct1/bitbar-dnscrypt-proxy-switcher
I think 1 is about OS defaults, not stuff users must know to do. People knowledgeable about privacy could always bolt things on, and that's quite orthogonal to this discussion. Rather, this is all about the people who do no installation/configuration beyond an OS and a browser.
https://www.dnscrypt.info
The .org is not legit.
The .org is not legit.
So sorry, my bad. Mobile Google fail :( thanks for vetting !
> DoH providers have committed to far stronger privacy protections.
What about DNS tampering? In many countries there are different rules for taking down a website. My ISP applies different rules than 8.8.8.8, which is handy when required by law in France but not in USA.
Effectively, government-mandated tampering will be applied with much less granularity because of centralization (or bi-centralization).
What about DNS tampering? In many countries there are different rules for taking down a website. My ISP applies different rules than 8.8.8.8, which is handy when required by law in France but not in USA.
Effectively, government-mandated tampering will be applied with much less granularity because of centralization (or bi-centralization).
In addition to (2), I imagine it's easier to set up a completing DoH service and get it included in Firefox than an ISP that can reach a similar number of users. So it may not always be so centralized.
[deleted]
The ISP can just check which IP you contact, so I don't see this increasing privacy.
That doesn't work anymore. ISPs are not going to block AWS IP ranges or Azure IP ranges, etc. The cloud killed IP blocking. The pirate bay is supposed to be blocked in UK by court order, but because they use cloudflare it's still accessible and only DNS blocked.
> ISPs are not going to block AWS IP ranges or Azure IP ranges, etc.
Tell that to China, Iran, Turkey (?), etc.
Tell that to China, Iran, Turkey (?), etc.
Ok, authoritarian regimes not included
> Ok, authoritarian regimes not included
And yet this was/is one of the justifications for implementing this.
They're not doing it in the EU because (a) there are decent privacy laws, and (b) IP addresses are (IIRC) considered personal information and so Cloudflare DoH would be responsible for keep a whole bunch of data safe. They may not want that responsibility.
This seems to (currently) be US-only because of the sucky US privacy laws.
And yet this was/is one of the justifications for implementing this.
They're not doing it in the EU because (a) there are decent privacy laws, and (b) IP addresses are (IIRC) considered personal information and so Cloudflare DoH would be responsible for keep a whole bunch of data safe. They may not want that responsibility.
This seems to (currently) be US-only because of the sucky US privacy laws.
No the justification is to make it harder for non-authoritarian countries to block websites. If China or North Korea want to block the IP range of AWS+Azure+Google that's up to their respective autocrats.
Most democratic or even hybrid regimes are not prepared for that level of absolute chaos and consequent protest if half the Internet is shut down. You can only pull that shit in a dictatorship.
Most democratic or even hybrid regimes are not prepared for that level of absolute chaos and consequent protest if half the Internet is shut down. You can only pull that shit in a dictatorship.
This is addressed in TFA: The fact that there are multiple problems and solving any one of them doesn't help much until they're all solved, should not be an excuse to refuse to solve any of them.
So you have a "solution" that doesn't really solve the problem, and also create a new privacy problem (now cloudflare has your data too). Hence it's actually a privacy loss.
For some (large, especially) sites, the IP address maps to the entity you're trying to contact. For others (small, especially) sites, the IP address is shared among many entities... not just shared origin hosts but also the massive reverse proxies of the world (Cloudflare, etc.).
There is an actual research on this. More than 90% of alexa's top 1 million websites (more like 95% or so) are uniquely identifiable just by IP addresses you connect to when you visit them. This is not a single IP address per website, but multiple, because websites include subresources with other IP addresses to connect to.
On top of that, there is a pressure on CDNs and clouds to make websites stick to specific IP addresses and make them blockable by IP addresses without affecting other customers. So far they have proven to not go against this pressure and even made technical solutions to aid governments to identify websites by IP addresses, in particular by fixing L7 routing layer to block domain fronting (which is important, because ESNI is basically domain fronting, but crappy, and the pressure didn't go anywhere, so there is the same pressure to make sure ESNI doesn't interfere with identification of websites you are visiting).
On top of that, there is a pressure on CDNs and clouds to make websites stick to specific IP addresses and make them blockable by IP addresses without affecting other customers. So far they have proven to not go against this pressure and even made technical solutions to aid governments to identify websites by IP addresses, in particular by fixing L7 routing layer to block domain fronting (which is important, because ESNI is basically domain fronting, but crappy, and the pressure didn't go anywhere, so there is the same pressure to make sure ESNI doesn't interfere with identification of websites you are visiting).
How would they force cloud providers customers to host on an ip? Do you envision restrictig new instances with manual approvals required?
Also, Cloudflare does give Business and Enterprise customers their own IP addresses (although often rotated) so that these sites work with old non-SNI browsers.
And until ESNI gets high adoption they can also just look at the SNI header. I do not see how DoH gives any significant amount of extra privacy.
DoH doesn't need to provide extra privacy to make sense (although it is a mandatory stepping stone to good privacy). It also provides a difficult to block security upgrade (as opposed to DoT, which is easy to block).
We've seen regular US ISPs hijack unencrypted DNS to insert content or replace sites entirely. We've also seen bad actors do far worse on public WiFi.
So acting like DoH is a waste of time unless every part of the privacy puzzle is online is wrong-headed. It is a huge step in the right direction for privacy, increase their costs, and will be much needed when eSNI is online. In the meantime "all" we get is a huge security improvement.
We've seen regular US ISPs hijack unencrypted DNS to insert content or replace sites entirely. We've also seen bad actors do far worse on public WiFi.
So acting like DoH is a waste of time unless every part of the privacy puzzle is online is wrong-headed. It is a huge step in the right direction for privacy, increase their costs, and will be much needed when eSNI is online. In the meantime "all" we get is a huge security improvement.
Except, not really. If you're worried about DNS tampering, DNSSEC already exists all the way up to the root servers.
If you're worried about ISPs snooping on what sites you visit, they'll continue to be able to do this even with widespread DoH/DoT and ESNI adoption. You still need to connect to an IP and TLS certs still have unique serials (most of which appear on public CT logs). Correlated over a large user population, that's more than enough to get a pretty decent, aggregate view of what sites you're browsing (certainly enough to tailor ads/marketing towards you).
As for random third party networks (e.g. Starbucks wifi), if you're not using a VPN then I don't see what expectation of privacy/security you had in the first place.
Ultimately, if you don't trust your ISP (or whatever network you happen to be connected to), the only meaningful option is a VPN. Encrypting your DNS traffic to a resolver (whether with DoH or DoT) is, at best, a very incremental improvement in the arms race. It protects users against some of the most egregious ISP abuses (assuming said ISP doesn't also spoof the cert...) at the expense of potentially misleading them into thinking they have more privacy than they actually do. In the case of DoH it will also likely inadvertently end up centralising a huge chunk of DNS lookups in to the hands of a few large corporations thanks to it being opt-out rather than opt-in. At least DoT avoids that (and offers server-to-server encryption).
Much better for users who want unfettered internet access and privacy to encrypt the whole lot with a VPN and use a resolver that validates DNSSEC. If the chain of resolvers were all DoT enabled that would definitely be a nice extra but hardly essential.
Alternatively, if you're in a country with a healthy ISP market (and government you're not afraid of), there's always the option to simply move to a provider that doesn't tamper with and monetise user traffic.
If you're worried about ISPs snooping on what sites you visit, they'll continue to be able to do this even with widespread DoH/DoT and ESNI adoption. You still need to connect to an IP and TLS certs still have unique serials (most of which appear on public CT logs). Correlated over a large user population, that's more than enough to get a pretty decent, aggregate view of what sites you're browsing (certainly enough to tailor ads/marketing towards you).
As for random third party networks (e.g. Starbucks wifi), if you're not using a VPN then I don't see what expectation of privacy/security you had in the first place.
Ultimately, if you don't trust your ISP (or whatever network you happen to be connected to), the only meaningful option is a VPN. Encrypting your DNS traffic to a resolver (whether with DoH or DoT) is, at best, a very incremental improvement in the arms race. It protects users against some of the most egregious ISP abuses (assuming said ISP doesn't also spoof the cert...) at the expense of potentially misleading them into thinking they have more privacy than they actually do. In the case of DoH it will also likely inadvertently end up centralising a huge chunk of DNS lookups in to the hands of a few large corporations thanks to it being opt-out rather than opt-in. At least DoT avoids that (and offers server-to-server encryption).
Much better for users who want unfettered internet access and privacy to encrypt the whole lot with a VPN and use a resolver that validates DNSSEC. If the chain of resolvers were all DoT enabled that would definitely be a nice extra but hardly essential.
Alternatively, if you're in a country with a healthy ISP market (and government you're not afraid of), there's always the option to simply move to a provider that doesn't tamper with and monetise user traffic.
> TLS certs still have unique serials
In TLS 1.3 everything sent by the server, including its certificate, is encrypted.
This is possible because of a re-ordering of considerations. It used to be that the conversation starts like this:
Client: "Hi, I want to talk to Server?"
Server: "Here's a certificate for Server, which is me"
Client: [ "Secret is 123456" encrypted using the Public Key from the certificate for Server ]
Server: [ "See, it's me" encrypted using the secret 123456 ]
But in TLS 1.3 it starts like this:
Client: "Hi, I want to talk to Server and I used ECDHE to pick this number 123"
Server: "I used ECDHE and I picked 456..." [ "I am Server, here's a Certificate for Server, and here's a signature proving the conversation we're having right now is with me, Server, which you can verify using the Public Key in that Certificate" encrypted using the secret 987654 ]
ECDHE allows Client and Server to agree the secret key 987654 even though the information they publish to agree on it (123 and 456) is public for anyone to see. Its predecessor Diffie Hellman is easier to understand if you never got past high school mathematics, so research that if you've never seen this trick before.
You'll notice this is also less round trips (so better performance over high latency links) as well as being more secure and more future-proof.
In TLS 1.3 everything sent by the server, including its certificate, is encrypted.
This is possible because of a re-ordering of considerations. It used to be that the conversation starts like this:
Client: "Hi, I want to talk to Server?"
Server: "Here's a certificate for Server, which is me"
Client: [ "Secret is 123456" encrypted using the Public Key from the certificate for Server ]
Server: [ "See, it's me" encrypted using the secret 123456 ]
But in TLS 1.3 it starts like this:
Client: "Hi, I want to talk to Server and I used ECDHE to pick this number 123"
Server: "I used ECDHE and I picked 456..." [ "I am Server, here's a Certificate for Server, and here's a signature proving the conversation we're having right now is with me, Server, which you can verify using the Public Key in that Certificate" encrypted using the secret 987654 ]
ECDHE allows Client and Server to agree the secret key 987654 even though the information they publish to agree on it (123 and 456) is public for anyone to see. Its predecessor Diffie Hellman is easier to understand if you never got past high school mathematics, so research that if you've never seen this trick before.
You'll notice this is also less round trips (so better performance over high latency links) as well as being more secure and more future-proof.
This is very cool. Thanks for the great explanation!
In addition to 1) ideally the user can just choose here. Which the user currently sort of can, so I don't see a problem with it.
For point 1, Windows 10 plans to implement this.
Questions I couldn’t find answers to in the post or linked info about the Trusted Resolver Program:
What’s in it for the Cloudflare & NextDNS?
Are they getting paid to handle this traffic or paying to have the opportunity to access this data?
Can users outside the US opt-in?
The comment about having “no plans” to enable this outside the USA seems a bit disingenuous. Hard to believe they built this program / feature and have no plan to eventually roll out to all users. Perhaps what they wanted to say was they have no fixed timeline for roll out to other locations.
What’s in it for the Cloudflare & NextDNS?
Are they getting paid to handle this traffic or paying to have the opportunity to access this data?
Can users outside the US opt-in?
The comment about having “no plans” to enable this outside the USA seems a bit disingenuous. Hard to believe they built this program / feature and have no plan to eventually roll out to all users. Perhaps what they wanted to say was they have no fixed timeline for roll out to other locations.
Yes, if you press the network and proxy settings in the preferences page, you will see a DNS over HTTPS setting. You can also use this to set your own resolver in case you dont trust cloudflare.
> The comment about having “no plans” to enable this outside the USA seems a bit disingenuous
The comment actually very clearly says "we do not have plans to roll out the feature in Europe or other regions at this time".
Also I have mixed feelings about this. On one hand yeah, encryption is great and someone sitting between me and my ISP will no longer be able to monitor my DNS queries. On the other hand I don't feel like this is protecting me from anything at this time. Instead of trusting my ISP, I have to trust Cloudflare. And in the meantime my ISP still knows where I am connecting to, between looking at the IP and the SNI (they mention ESNI but we're not there yet and it still just a partial fix).
DoH (in general, not Mozilla's problem) just enables any piece of software or hardware on my network to bypass any security controls I have in place. No more filtering DNS with things like PiHole, no more blocking DNS port on your firewall. This tends to work out great for Google and any random IoT device manufacturer. I could cover this with more enterprisey setups but that's the last thing I want to do at home.
So the average user probably sees no difference either way, nothing lost, nothing gained. But for me it's a clear regression because I lose the little control I had over that traffic and I just spread more data around to yet more companies. Some may even be in legal jurisdictions that are even less trustworthy than where my ISP is located.
The comment actually very clearly says "we do not have plans to roll out the feature in Europe or other regions at this time".
Also I have mixed feelings about this. On one hand yeah, encryption is great and someone sitting between me and my ISP will no longer be able to monitor my DNS queries. On the other hand I don't feel like this is protecting me from anything at this time. Instead of trusting my ISP, I have to trust Cloudflare. And in the meantime my ISP still knows where I am connecting to, between looking at the IP and the SNI (they mention ESNI but we're not there yet and it still just a partial fix).
DoH (in general, not Mozilla's problem) just enables any piece of software or hardware on my network to bypass any security controls I have in place. No more filtering DNS with things like PiHole, no more blocking DNS port on your firewall. This tends to work out great for Google and any random IoT device manufacturer. I could cover this with more enterprisey setups but that's the last thing I want to do at home.
So the average user probably sees no difference either way, nothing lost, nothing gained. But for me it's a clear regression because I lose the little control I had over that traffic and I just spread more data around to yet more companies. Some may even be in legal jurisdictions that are even less trustworthy than where my ISP is located.
> DoH just enables any piece of software or hardware on my network to bypass any security controls I have in place.
I think this is an error in how you've thought about the problem. If your "security controls" depend upon other people volunteering to use some protocol then those weren't "security controls" they were more like "guidelines".
[ My local airport has a sign and a telephone so that if you've arrived with goods that are forbidden or without permission to enter the country you can call up the relevant authorities and have them come fine or arrest you. The telephone looks dusty. Do you think maybe people just decide not to call? ]
Mozilla does also have a programme https://iot.mozilla.org/ about how to design IoT devices that allow their owners to control them rather than trying to bodge things by hoping they use protocols you can intercept.
I think this is an error in how you've thought about the problem. If your "security controls" depend upon other people volunteering to use some protocol then those weren't "security controls" they were more like "guidelines".
[ My local airport has a sign and a telephone so that if you've arrived with goods that are forbidden or without permission to enter the country you can call up the relevant authorities and have them come fine or arrest you. The telephone looks dusty. Do you think maybe people just decide not to call? ]
Mozilla does also have a programme https://iot.mozilla.org/ about how to design IoT devices that allow their owners to control them rather than trying to bodge things by hoping they use protocols you can intercept.
> If your "security controls" depend upon other people volunteering to use some protocol then those weren't "security controls" they were more like "guidelines".
It isn't really a matter of security controls. Anything has always been able to create an encrypted tunnel on TCP/443 and send whatever over it.
The issue is administrative cost for cooperative applications. You have a local DNS that e.g. blocks known malicious domains and has the local names for other devices on your LAN. The user of each device doesn't want to prevent this, the application developer doesn't want to prevent it, but making that happen when applications default to using a third party DNS goes from setting the DNS via DHCP to changing a separate setting in every application on every device.
The suggested solution to this is to have the local DNS resolve a canary domain in a particular way which Firefox takes as a request not to use DoH by default. That basically works, but I still don't know what they intend to do when adversarial upstream DNS servers start resolving the canary domain that way. It would also work a lot better if there was a standard canary domain instead of every application making up their own.
It isn't really a matter of security controls. Anything has always been able to create an encrypted tunnel on TCP/443 and send whatever over it.
The issue is administrative cost for cooperative applications. You have a local DNS that e.g. blocks known malicious domains and has the local names for other devices on your LAN. The user of each device doesn't want to prevent this, the application developer doesn't want to prevent it, but making that happen when applications default to using a third party DNS goes from setting the DNS via DHCP to changing a separate setting in every application on every device.
The suggested solution to this is to have the local DNS resolve a canary domain in a particular way which Firefox takes as a request not to use DoH by default. That basically works, but I still don't know what they intend to do when adversarial upstream DNS servers start resolving the canary domain that way. It would also work a lot better if there was a standard canary domain instead of every application making up their own.
> If your "security controls" depend upon other people volunteering to use some protocol then those weren't "security controls" they were more like "guidelines".
It's not about volunteering. Previously I could block udp/53 and tcp/53 and be confident of the fact that no DNS look ups would happen. (DNS queries over other ports could be caught doing packet sniffing.)
Now I have to worry about DNS queries going out via HTTPS. So if I want to monitor my network for malware contacting a C&C server I have to snoop HTTPS. Which means I now have to install a web proxy and perhaps do MITM.
Previously I could 'simply' monitor DNS look ups to see if anything was trying to connect to nefarious domains.
DoH has reduced visibility into my own network.
It's not about volunteering. Previously I could block udp/53 and tcp/53 and be confident of the fact that no DNS look ups would happen. (DNS queries over other ports could be caught doing packet sniffing.)
Now I have to worry about DNS queries going out via HTTPS. So if I want to monitor my network for malware contacting a C&C server I have to snoop HTTPS. Which means I now have to install a web proxy and perhaps do MITM.
Previously I could 'simply' monitor DNS look ups to see if anything was trying to connect to nefarious domains.
DoH has reduced visibility into my own network.
> Previously I could block udp/53 and tcp/53 and be confident of the fact that no DNS look ups would happen. ... Now I have to worry about DNS queries going out via HTTPS.
That confidence would have been misplaced. DoH offers a standardized protocol, but it's not exactly difficult to put together a one-off interface for performing occasional remote DNS lookups over HTTPS. One could even use existing HTTPS sites for the purpose (e.g. https://ping.eu/nslookup/).
That confidence would have been misplaced. DoH offers a standardized protocol, but it's not exactly difficult to put together a one-off interface for performing occasional remote DNS lookups over HTTPS. One could even use existing HTTPS sites for the purpose (e.g. https://ping.eu/nslookup/).
That is a good point, but it is also mostly independent from DoH, a VPN with an hardcoded IP would have worked in the same way (if you look into elusive VPNs you can also find some that work by injecting traffic into padding of another connection).
The only difference is if you are worrying about the traffic leaving your own browser and in that case you can just not enable DoH
The only difference is if you are worrying about the traffic leaving your own browser and in that case you can just not enable DoH
My passive network sniffers may throw red flags on suspicious traffic which may end up being VPN. By disguising non-web traffic over the (until now) web-mostly HTTPS, it makes the job of someone who wants to be a responsible netizen and monitor their network that much harder.
I agree if the point is that this might increase the reach of such technologies. But if you are thinking about traffic coming from sources different than your browser then why would they be unable to open a connection on hardcoded IPs?
Also VPN sniffing can be arbitrarily hard, for example if I remember correctly tools like https://www.softether.org/ are designed to work around the Chinese internet firewall.
From my point of view DoH add nothing outside the browser.
Also VPN sniffing can be arbitrarily hard, for example if I remember correctly tools like https://www.softether.org/ are designed to work around the Chinese internet firewall.
From my point of view DoH add nothing outside the browser.
So I should block outgoing TLS requests to be able to stop DoH?
Seems a bad idea....
At least with DNS I could run a local DNS server and block outgoing port 53 from anything else. Now I no longer have this option and each app gets to look up what it wants, when it wants. Sure, it's great that my ISP cannot see what's in these requests but nor can I! And it also means that any application (eg. any Google product) can query for advertising/tracking domains without me being able to do a thing about it.
It isn't solving a problem - it's creating a far, far worse one (for me).
If I have got this wrong, or there is a method around this - what is it???
Seems a bad idea....
At least with DNS I could run a local DNS server and block outgoing port 53 from anything else. Now I no longer have this option and each app gets to look up what it wants, when it wants. Sure, it's great that my ISP cannot see what's in these requests but nor can I! And it also means that any application (eg. any Google product) can query for advertising/tracking domains without me being able to do a thing about it.
It isn't solving a problem - it's creating a far, far worse one (for me).
If I have got this wrong, or there is a method around this - what is it???
Don't put devices on your network if you don't want to give them network access. And don't block technologies and protocols that help people protect themselves just because they also help devices protect themselves from you MITMing their connections. If you want to run a device reverse-engineering lab you have more work to do to break the security of a device.
Also remember that if you can break the security of a device, so could an ISP router. The correct behavior for devices is to treat the intermediate network between them and the servers they talk to as hostile.
How many people are using custom local plaintext DNS as a measure to analyze local devices on their network? How many more people are having their whole network's DNS usage analyzed by their ISP and anyone their ISP sells data to? The defaults are designed to be the right choice for people who don't change the defaults.
Also remember that if you can break the security of a device, so could an ISP router. The correct behavior for devices is to treat the intermediate network between them and the servers they talk to as hostile.
How many people are using custom local plaintext DNS as a measure to analyze local devices on their network? How many more people are having their whole network's DNS usage analyzed by their ISP and anyone their ISP sells data to? The defaults are designed to be the right choice for people who don't change the defaults.
"The correct behavior for devices is to treat the intermediate network between them and the servers they talk to as hostile."
Thanks for this - I had not thought of that.
Looks like I'll be keeping my "smart" TV off the network forever then (my old LG used to send a network request whenever I pressed any button on the remote)! And all my Android devices, Windows 10 devices and my Apple TV and MacBook too. (This is only partially sarcasm - I can't really trust anything these days it seems...). The amount of dialling-out they all do is astronomical. The only solution appears to be going full 1980s and not being on the network. The dream is over.
At least my Raspberry Pi can be trusted. Other than the GPU chipset...
Thanks for this - I had not thought of that.
Looks like I'll be keeping my "smart" TV off the network forever then (my old LG used to send a network request whenever I pressed any button on the remote)! And all my Android devices, Windows 10 devices and my Apple TV and MacBook too. (This is only partially sarcasm - I can't really trust anything these days it seems...). The amount of dialling-out they all do is astronomical. The only solution appears to be going full 1980s and not being on the network. The dream is over.
At least my Raspberry Pi can be trusted. Other than the GPU chipset...
This is precisely why many of us use Linux and put up with some of the inconveniences or doing so - it’s more trustworthy. (And it gets more convenient as more people start using it.)
> treat the intermediate network between them and the servers they talk to as hostile
Unfortunately they also treat the user as hostile and untrusted. Your phone, browser, OS, or TV treat you as hostile when they send data to the manufacturer and give you no way of assessing yourself or actually controlling this. We have standards and protocols that ensure the data is kept perfectly secure and inscrutable between your device and the manufacturer but absolutely nothing is put in place to give you any control over this. Your choice is binary: use it or not. Every security decision seems to work out better for those companies than for the user.
In this case both DoH and DoT provide the required security for the users but one of them takes a little bit of control away from them.
Unfortunately they also treat the user as hostile and untrusted. Your phone, browser, OS, or TV treat you as hostile when they send data to the manufacturer and give you no way of assessing yourself or actually controlling this. We have standards and protocols that ensure the data is kept perfectly secure and inscrutable between your device and the manufacturer but absolutely nothing is put in place to give you any control over this. Your choice is binary: use it or not. Every security decision seems to work out better for those companies than for the user.
In this case both DoH and DoT provide the required security for the users but one of them takes a little bit of control away from them.
The problem is that the device (or website) also treats the owner and legitimate user as untrusted and obfuscates the content of the traffic in a way that makes everything completely opaque for them. The device/site only trusts its manufacturer which makes any device that completely obscures its traffic from its owner feel more like a Trojan horse. This is how you end up with questionable telemetry and data leaks for example.
What's a "trustworthy" device in this circumstance? If you can never verify then it's not trust it's faith and hope.
What's a "trustworthy" device in this circumstance? If you can never verify then it's not trust it's faith and hope.
In what way does this argument not also suggest that the device should use plaintext HTTP so that you can intercept all its other traffic?
What I want is a key to my own house, not an open door. Right now using a lot of software and IoT devices feels like buying a house but the builders keep the only key.
> Don't run devices on your network you don't trust.
This advice is about as practical as "Do not use ISPs and their forwarders that you don't trust.". Which is to say, not much. Let us know about your experience with smart TVs and similar devices, and how much you trust them.
This advice is about as practical as "Do not use ISPs and their forwarders that you don't trust.". Which is to say, not much. Let us know about your experience with smart TVs and similar devices, and how much you trust them.
> Don't run devices on your network you don't trust.
Oh, is that all?
How about I trust the devices until a secretary clicks on a (spear)phishing link that runs a zero-day. Then what? The host is compromised so I can no longer trust any end-device monitoring software on it, and now the network traffic is opaque.
And that doesn't even get into things like academia where students and visiting researchers bring devices of unknown providence. If if they're on DMZed networks, they could be spewing garbage onto the Internet and getting my CIDR range blacklisted.
Oh, is that all?
How about I trust the devices until a secretary clicks on a (spear)phishing link that runs a zero-day. Then what? The host is compromised so I can no longer trust any end-device monitoring software on it, and now the network traffic is opaque.
And that doesn't even get into things like academia where students and visiting researchers bring devices of unknown providence. If if they're on DMZed networks, they could be spewing garbage onto the Internet and getting my CIDR range blacklisted.
So you're counting on malware's continued use of plaintext DNS as part of your network's security strategy?
If anything hits port 53 on the outgoing gateway, and it's not from our recursive servers, then we know that network element needs to be looked at: either it's mis-configured or malicious.
Anything that uses our recursive servers is monitored, and we can check against blacklists, either in real-time or after-the-fact through logging.
* https://en.wikipedia.org/wiki/Domain_generation_algorithm
* https://en.wikipedia.org/wiki/Botnet#Domains
If malware is connecting to hard-coded IPs then there's nothing we can do about that.
So yes: monitoring DNS for suspicious activity is part of our security strategy.
Anything that uses our recursive servers is monitored, and we can check against blacklists, either in real-time or after-the-fact through logging.
* https://en.wikipedia.org/wiki/Domain_generation_algorithm
* https://en.wikipedia.org/wiki/Botnet#Domains
If malware is connecting to hard-coded IPs then there's nothing we can do about that.
So yes: monitoring DNS for suspicious activity is part of our security strategy.
Then your security strategy definitely needs improvements, since malware often uses hardcoded IPs to bypass DNS proxying/forwarding that corporate networks use. Seriously, this argument could be used to say we should be using HTTP instead of HTTPS, but anyone doing security knows if they really need that level of introspection they need to MITM HTTPS traffic with a MITM proxy. If you care that much, you also need to MITM DoH/DoT traffic.
DNS sniffing takes care of a lot of low-hanging fruit.
Given that Cisco has a major product, Umbrella, that is sold as a part of enterprise security strategy I'd say that more than the OP is considering DNS filtering / monitoring as part of a network security strategy.
> If your "security controls" depend upon other people volunteering to use some protocol then those weren't "security controls" they were more like "guidelines"
> Security controls are safeguards or countermeasures to avoid, detect, counteract, or minimize security risks to physical property, information, computer systems, or other assets. [0]
Of course it's a security control. Not a perfect one but a security control nonetheless. And every security control of today might become useless tomorrow so I don't get your point. Is a firewall a "guideline" just because I can tunnel some illegitimate traffic through an accepted port? Are your house and car door locks "guidelines" because a thief has to "volunteer" to not break/pick them or go in through the window? So you'll take them all out until you have "real" security controls? I guessed not...
As for your airport example, given that illegal activities go unnoticed and items are smuggled through customs every day you could argue that there are no security controls in place and that the airport relies on people volunteering to not break the law. But you'd be using the wrong definition and understanding of what a security control is.
As far as home security goes having DNS filtering adds a layer on top of the "nothing" you normally have. And it's a pretty good and accessible way to achieve this extra bit of security. "Not perfect" does not equal "no security". And it's not even just security: ad-filtering, parental controls, privacy, etc. are all impacted. DoH all but guarantees that you lose this control and unfortunately there's nothing ready to take its place.
[0] https://en.wikipedia.org/wiki/Security_controls
> Security controls are safeguards or countermeasures to avoid, detect, counteract, or minimize security risks to physical property, information, computer systems, or other assets. [0]
Of course it's a security control. Not a perfect one but a security control nonetheless. And every security control of today might become useless tomorrow so I don't get your point. Is a firewall a "guideline" just because I can tunnel some illegitimate traffic through an accepted port? Are your house and car door locks "guidelines" because a thief has to "volunteer" to not break/pick them or go in through the window? So you'll take them all out until you have "real" security controls? I guessed not...
As for your airport example, given that illegal activities go unnoticed and items are smuggled through customs every day you could argue that there are no security controls in place and that the airport relies on people volunteering to not break the law. But you'd be using the wrong definition and understanding of what a security control is.
As far as home security goes having DNS filtering adds a layer on top of the "nothing" you normally have. And it's a pretty good and accessible way to achieve this extra bit of security. "Not perfect" does not equal "no security". And it's not even just security: ad-filtering, parental controls, privacy, etc. are all impacted. DoH all but guarantees that you lose this control and unfortunately there's nothing ready to take its place.
[0] https://en.wikipedia.org/wiki/Security_controls
Why? If you know how to run your own pihole, you know how to turn off DoH? You're not being forced into this, a default setting is getting flipped and you're entirely free to go "no thanks" and flip it back, so if you trust whoever owns the IP that you're using as real, unencrypted DNS server, then just keep using that. Same as for folks who want to keep using unencrypted emails "because encrypted mail isn't fully encrypted anyway and just makes things harder".
As tech changes, solutions change, but at least for the foreseeable future your DNS intercept will keep working just fine until everyone switches over to DoH and stops offering an opt-out.
As tech changes, solutions change, but at least for the foreseeable future your DNS intercept will keep working just fine until everyone switches over to DoH and stops offering an opt-out.
> DoH (in general, not Mozilla's problem)
Parsing the text helps with understanding it. And the fact that Mozilla allows me to flip back says nothing about those general cases. I do not expect everyone to give you the choice.
Parsing the text helps with understanding it. And the fact that Mozilla allows me to flip back says nothing about those general cases. I do not expect everyone to give you the choice.
You may find it noteworthy that Mozilla provides ways to configure this behavior as you please: https://github.com/mozilla/policy-templates#dnsoverhttps
> DoH (in general, not Mozilla's problem)
You may find noteworthy that my comment had 2 points. One where I don’t feel like DoH will bring much benefit in the browser today, and one where DoH in general will just give you, the user, even less control over what you’re sending out. I can’t imagine everyone giving you the option to switch, all the TRRs being actually trusted, or even being able to pick the TRR in most setups (IoT? Your random Google product?).
You may find noteworthy that my comment had 2 points. One where I don’t feel like DoH will bring much benefit in the browser today, and one where DoH in general will just give you, the user, even less control over what you’re sending out. I can’t imagine everyone giving you the option to switch, all the TRRs being actually trusted, or even being able to pick the TRR in most setups (IoT? Your random Google product?).
[deleted]
> What’s in it for the Cloudflare & NextDNS?
It gives them a competitive advantage in DNS industry against other B2B providers, such as NS1.
It gives them a competitive advantage in DNS industry against other B2B providers, such as NS1.
How?
Surely the only way that's possible is if they derive data about users, which they can then sell .. which is what Mozilla claim to be preventing.
Surely the only way that's possible is if they derive data about users, which they can then sell .. which is what Mozilla claim to be preventing.
Cloudflare's resolver does not send the client subnet, which hurts performance when users connect to anything that doesn't use Cloudflare.
That's one thing, sure, but that doesn't affect the majority of sites. CF's DNS POPs are likely more dense than the great majority of service providers POPs. So using the subnet of the resolver is about as good (if not better) than having ECS info for practical purposes. (Because the client is normally going to hit the closest DNS POP to them in BGP network distance.)
I'm not a CF fanboi, in fact I think they are evil. But let's not make weak arguments. That said, yeah suppression of ECS info is a deliberate anti-competitive choice by CF. They probably have convinced themselves its about privacy, but it isn't.
The real benefit to them is, as the CDN, they get the benefit of even lower latency and even better control. With a penalty to everyone else.
It's a disgusting arrangement, and a net loss in privacy. Your ISP already knows what websites you visit, they don't need the DNS because they see the actual traffic.
I'd find it more palatable if these so-called TRR providers were required to be DNS-only. Maybe DNS + registrar.
I'm not a CF fanboi, in fact I think they are evil. But let's not make weak arguments. That said, yeah suppression of ECS info is a deliberate anti-competitive choice by CF. They probably have convinced themselves its about privacy, but it isn't.
The real benefit to them is, as the CDN, they get the benefit of even lower latency and even better control. With a penalty to everyone else.
It's a disgusting arrangement, and a net loss in privacy. Your ISP already knows what websites you visit, they don't need the DNS because they see the actual traffic.
I'd find it more palatable if these so-called TRR providers were required to be DNS-only. Maybe DNS + registrar.
>Your ISP already knows what websites you visit, they don't need the DNS because they see the actual traffic.
Then why were the big ISPs lobbying against this plan when proposed by Google originally? Because they truly were concerned for the welfare of the Internet as they claimed? This is a concern they've never exhibited in the past, their only demonstrated concerns have been related to their revenue streams.
Then why were the big ISPs lobbying against this plan when proposed by Google originally? Because they truly were concerned for the welfare of the Internet as they claimed? This is a concern they've never exhibited in the past, their only demonstrated concerns have been related to their revenue streams.
> How?
Running a public DNS service allows Cloudflare and NextDNS to provide faster and smoother DNS updates to their B2B customers by avoiding third-party DNS resolvers and caches.
Running a public DNS service allows Cloudflare and NextDNS to provide faster and smoother DNS updates to their B2B customers by avoiding third-party DNS resolvers and caches.
curious, can see the case for the capability giving advantage, but how do you think running the public service would? or do you mean competitive advantage in marketing their products?
[deleted]
> having “no plans” to enable this outside the USA seems a bit disingenuous.
Other countries have censorship (China, UK, New Zealand, etc) whereas there is none in the US.
I wonder if that’s why?
Other countries have censorship (China, UK, New Zealand, etc) whereas there is none in the US.
I wonder if that’s why?
Mozilla was founded in USA, which may be of relevance for why USA was selected as the country of launch. I don’t know anything specific about their decision, though.
it's probably because cloudflare and friends went "we want to see what hit we're taking if we do this for free for you, by only enabling this by default for the US first" or something.
Huh? It works for me in the Netherlands, at least, it is in the settings. How to confirm if I'm using it?
If you use it, presumably you can make a GDPR claim to find out way Cloudflare are doing with the data?
After eSNI becomes mainstream, network level ad blocking will be extremely difficult. My guess is there will be a huge ad blocking subscription play in the future.
They’re usurping control and calling it a privacy enhancement so they can sell the control back to us with per user per month pricing.
They’re usurping control and calling it a privacy enhancement so they can sell the control back to us with per user per month pricing.
Will they roll it out in Canada? Raising eyebrow and thinking if it has anything to do with GDPR
Collect data of course. Mozilla is very naive to trust that they won't collect data (be it personal or otherwise). Neither they nor the enduser can ensure that.
In order to be included in Firefox, they needed to agree to the DOH-resolver policy[1]. That states that:
> We intend to publicly document violations of this Policy and take additional actions if necessary.
I believe that those "additional actions" will prevent providers from violating the policy. If not, they will be removed from Firefox.
[1] https://wiki.mozilla.org/Security/DOH-resolver-policy
> We intend to publicly document violations of this Policy and take additional actions if necessary.
I believe that those "additional actions" will prevent providers from violating the policy. If not, they will be removed from Firefox.
[1] https://wiki.mozilla.org/Security/DOH-resolver-policy
Mozilla doesn't trust. That's what the legal team is for. All this stuff is covered by contracts and audits.
Who is more likely to abuse it though, those guys or your ISP? Security is never 100%, it's whack-a-mole
> What’s in it for the Cloudflare & NextDNS?
I'm amazed noone else is asking this. CF's whole business model centres around the concept of denying website access to minorities they classify as "bots". Some big actors can afford to practice the notion of reciprocity by blocking access to Cloudflare in return — https://news.ycombinator.com/item?id=21155056 — try doing that now when you might end up blocking access to your site for all Firefox users.
I'm amazed noone else is asking this. CF's whole business model centres around the concept of denying website access to minorities they classify as "bots". Some big actors can afford to practice the notion of reciprocity by blocking access to Cloudflare in return — https://news.ycombinator.com/item?id=21155056 — try doing that now when you might end up blocking access to your site for all Firefox users.
Doth protest too much.
People don’t take issue with DoH, they take issue with an advertising supported browser like Mozilla’s unicast (and now bicast) centralization of DNS traffic that was previously distributed.
We invented DNSCrypt. There’s also DNS over TLS. Lots of ways to encrypt DNS without centralization.
They make this about DoH when really the primary issues are with how they went about it.
People don’t take issue with DoH, they take issue with an advertising supported browser like Mozilla’s unicast (and now bicast) centralization of DNS traffic that was previously distributed.
We invented DNSCrypt. There’s also DNS over TLS. Lots of ways to encrypt DNS without centralization.
They make this about DoH when really the primary issues are with how they went about it.
DNS over TLS and DNSCrypt both depend on servers... exactly as centralized as DoH. They are just different wire protocols that in the end do the exact same thing with a centralized DNS server.
In fact, the only meaningful difference between DoH and DoT is that DoT runs on a separate port, so network operators (and ISPs) can filter it. DoT is DoH with a kill switch.
DoH can be blocked by IP addresses, DNS canary and probably SNI, while DoT by IP addresses and port number. So "DoT is DoH with a kill switch." is again nonsense.
Virtually every router on the Internet has the built-in capability to block DoT with a single configuration change, but you can attempt to create a blacklist of DoH resolvers to try to stop that, so they're totally equivalent. That's the argument you've got.
Not quite.
Nothing prevents Google or Cloudflare to run DoH on the same IPs as their user-facing services. Unless you are willing to block Search, for example, you might be SOL without TLS-terminating proxy.
Nothing prevents Google or Cloudflare to run DoH on the same IPs as their user-facing services. Unless you are willing to block Search, for example, you might be SOL without TLS-terminating proxy.
Yes, sorry if I wasn't clear, I think the idea that DoH is just as filterable as DoT is silly.
So one is easy to block and the other is hard, requiring maintaining a blacklist and or deep packet inspection. I'll take the hard one please.
Just increase the cost/difficulty of a thing makes that thing less common. In this case that "thing" is ISPs selling highly accurate web histories to anyone who will pay. Please make that harder/more expensive, every cent of cost to the ISP is welcomed.
Just increase the cost/difficulty of a thing makes that thing less common. In this case that "thing" is ISPs selling highly accurate web histories to anyone who will pay. Please make that harder/more expensive, every cent of cost to the ISP is welcomed.
This is not the full picture if we are being honest with ourselves. When DoH is default on in all browsers, the masses will be talking to 2 or 3 companies. Sure, they can change what server they talk to, but we all know that most people won't even think about it. DoT implemented on all DNS servers would keep control as distributed as it has been up until now. Until the root serves support DoT, which I doubt they ever will, there will always be weak links. This includes from Cloudflare, Mozilla and others talking to the root servers. I am not trying to convince anyone of anything. This is a very polarizing topic and has been every time it is discussed here and other news aggregators. The best I can do is educate people that I care about so they can make an informed decision.
DOH can also be implemented on every server.
People keep talking past each other on this because somehow DoH got conflated with Cloudflare.
DoH is a protocol. It has better security than unencrypted DNS. (So do several others, like DNSCurve, DNSCrypt, or routing your DNS queries over a VPN.)
The objection people have is not that it's encrypted, it's that Mozilla implemented it in the browser instead of the OS and thereby ignores the DNS you configured in your OS. And even that is fine as a setting you can enable, but it's problematic as the default. Both because it's administratively burdensome to change a setting in every application on every device if you want to use your own, and because of the second order effect of that, which is that hardly anybody will change it and then DNS becomes centralized to whatever is the default in the browsers.
DoH is a protocol. It has better security than unencrypted DNS. (So do several others, like DNSCurve, DNSCrypt, or routing your DNS queries over a VPN.)
The objection people have is not that it's encrypted, it's that Mozilla implemented it in the browser instead of the OS and thereby ignores the DNS you configured in your OS. And even that is fine as a setting you can enable, but it's problematic as the default. Both because it's administratively burdensome to change a setting in every application on every device if you want to use your own, and because of the second order effect of that, which is that hardly anybody will change it and then DNS becomes centralized to whatever is the default in the browsers.
If you're worried about your ISP snooping on you and tampering with DNS records, the tools we have today already offer better privacy and trust than DoH, DoT, DNSCurve or DNSCrypt.
Just use a DNSSEC capable resolver in combination with a VPN. All other options today are effectively theater.
Just use a DNSSEC capable resolver in combination with a VPN. All other options today are effectively theater.
DNSSEC is the least useful of the lot. It only authenticates, doesn't encrypt, so it's not enough on its own, you have to use it in combination with a VPN. But the VPN would be enough on its own between the client and the recursive DNS, since it does both.
Between the recursive and authoritative DNS the VPN wouldn't exist, but if the attacker is there then DNSSEC is in trouble again because it still doesn't encrypt (no confidentiality). What can be used on that path is DNSCurve, because it does encrypt even where there isn't a VPN.
The majority of domains also aren't DNSSEC signed anyway, so it doesn't even authenticate them.
Between the recursive and authoritative DNS the VPN wouldn't exist, but if the attacker is there then DNSSEC is in trouble again because it still doesn't encrypt (no confidentiality). What can be used on that path is DNSCurve, because it does encrypt even where there isn't a VPN.
The majority of domains also aren't DNSSEC signed anyway, so it doesn't even authenticate them.
You're conflating privacy with trust. DNSSEC gives you trust, the VPN gives you "last mile" privacy. DoH is only designed for last mile so useless in encrypting the resolver chain between you and the root servers.
Currently there is no way to get a fully encrypted chain (the root servers would need to support DoT or something similar and they don't nor are there any plans for them to do so afaik).
So the best (form a privacy and trust PoV) you can achieve is as I've outlined: VPN together with a DNSSEC resolver (with verification enabled). Over time you can hope for DoT to gain wider adoption so more and more of the upstream resolver chain is encrypted.
Currently there is no way to get a fully encrypted chain (the root servers would need to support DoT or something similar and they don't nor are there any plans for them to do so afaik).
So the best (form a privacy and trust PoV) you can achieve is as I've outlined: VPN together with a DNSSEC resolver (with verification enabled). Over time you can hope for DoT to gain wider adoption so more and more of the upstream resolver chain is encrypted.
DoH mitigates the "ISP selling your DNS data" threat, which practically everyone in the US faces, without forcing all your traffic onto a VPN, which not everyone wants. Meanwhile: practically no important zones are signed, so apart from the fact that DNSSEC does nothing to improve privacy, it's also not useful. DNSSEC is moribund; taking steps to enable it is a waste of time.
DoT would also mitigate it in a similar fashion. In both cases mitigate doesn't really have much meaning since, sans VPN, ISPs that are inclined to do so will quite happily continue to find ways to infer where you're browsing to (IP address and CT log correlation being the obvious choices). Ergo, if last mile privacy is you're issue, the best bet is a VPN or some improved regulation so that consumers have a choice if they want an ISP that doesn't spy on them.
DoT and DoH have virtually identical service models. The practical difference between the two is that DoT deliberately runs on a nonstandard port, so that network operators can filter it. It's not an exaggeration to say that DoT is simply DoH with a network kill switch.
When was the last time port 995 or 993 were blocked? If the same adoption happened with DoT, ISPs wouldn't have the option - customers wouldn't accept it.
> You're conflating privacy with trust.
Confidentiality and authentication are two different things, but the things that provide confidentiality here also provide authentication. DNSSEC only provides authentication, so then you need something else to provide confidentiality at every point in the path. At which point you would also have authentication at every point in the path, so what does that leave for DNSSEC to do?
> DoH is only designed for last mile so useless in encrypting the resolver chain between you and the root servers.
This is true. DoH isn't the one to use between recursive and authoritative DNS servers.
> Currently there is no way to get a fully encrypted chain (the root servers would need to support DoT or something similar and they don't nor are there any plans for them to do so afaik).
DoT has a similar drawback as DoH between recursive and authoritative servers. The session establishment is expensive (more round trips, higher latency). That's not so bad for the link between the client and the recursive DNS, because you create a session once and use it for all your queries. It stinks between recursive and authoritative servers because the recursive server would need a new session for each authoritative server -- and a single recursive query can often require contacting three or more authoritative servers.
Fortunately DNSCurve has lower latency and can be used between any pair of recursive and authoritative servers that support it.
The root not supporting DNSCurve is an issue, but it has an obvious long-term solution (have the root start supporting DNSCurve), and in the meantime the recursive resolver could validate only the root with DNSSEC. The lack of privacy is much less impactful for TLD queries -- a query for your-local-oncologist.com tells an observer much more than a query for .com. Then if DNSCurve is used for the rest of the chain after the root, you have one authentication or the other for the full chain and privacy for all but the TLD query. You also then don't need any large DNSSEC records in the authoritative servers that support DNSCurve, which would otherwise be a DDoS vector.
> So the best (form a privacy and trust PoV) you can achieve is as I've outlined: VPN together with a DNSSEC resolver (with verification enabled).
I still don't see what that's even supposed to be adding over the VPN right now. The VPN handles the link between the client and the recursive resolver. You can only get authentication between recursive and authoritative servers for domains whose authoritative servers support some authentication, but hardly any of them support any authentication right now, and if you're going to add one it makes more sense for it to be DNSCurve than DNSSEC because it provides confidentiality in addition to authentication and isn't a DDoS vector.
Confidentiality and authentication are two different things, but the things that provide confidentiality here also provide authentication. DNSSEC only provides authentication, so then you need something else to provide confidentiality at every point in the path. At which point you would also have authentication at every point in the path, so what does that leave for DNSSEC to do?
> DoH is only designed for last mile so useless in encrypting the resolver chain between you and the root servers.
This is true. DoH isn't the one to use between recursive and authoritative DNS servers.
> Currently there is no way to get a fully encrypted chain (the root servers would need to support DoT or something similar and they don't nor are there any plans for them to do so afaik).
DoT has a similar drawback as DoH between recursive and authoritative servers. The session establishment is expensive (more round trips, higher latency). That's not so bad for the link between the client and the recursive DNS, because you create a session once and use it for all your queries. It stinks between recursive and authoritative servers because the recursive server would need a new session for each authoritative server -- and a single recursive query can often require contacting three or more authoritative servers.
Fortunately DNSCurve has lower latency and can be used between any pair of recursive and authoritative servers that support it.
The root not supporting DNSCurve is an issue, but it has an obvious long-term solution (have the root start supporting DNSCurve), and in the meantime the recursive resolver could validate only the root with DNSSEC. The lack of privacy is much less impactful for TLD queries -- a query for your-local-oncologist.com tells an observer much more than a query for .com. Then if DNSCurve is used for the rest of the chain after the root, you have one authentication or the other for the full chain and privacy for all but the TLD query. You also then don't need any large DNSSEC records in the authoritative servers that support DNSCurve, which would otherwise be a DDoS vector.
> So the best (form a privacy and trust PoV) you can achieve is as I've outlined: VPN together with a DNSSEC resolver (with verification enabled).
I still don't see what that's even supposed to be adding over the VPN right now. The VPN handles the link between the client and the recursive resolver. You can only get authentication between recursive and authoritative servers for domains whose authoritative servers support some authentication, but hardly any of them support any authentication right now, and if you're going to add one it makes more sense for it to be DNSCurve than DNSSEC because it provides confidentiality in addition to authentication and isn't a DDoS vector.
DNSCurve sounds quite nice (I'm not at all familiar with it tbh). I agree something along those lines with DNSSEC for the last hop to the root would do it.
To be honest my main gripe is with DoH. For non-last-mile privacy/trust, there are indeed many suitable ways to tackle it.
To be honest my main gripe is with DoH. For non-last-mile privacy/trust, there are indeed many suitable ways to tackle it.
While that is true, it would be much easier to get DoT deployed at scale. During DNS Flag Day of 2019 [1] a significant number of recursive DNS servers around the world started properly supporting EDNS0 and several other modern features of DNS. In most cases, it was just application version updates or configuration changes. Most of the popular and widely deployed recursive DNS servers already support DoT, which means that a similar effort could be made to enable DoT. AFAIK none or few of the popular recursive DNS servers support DoH today natively. It would be significantly easier to get DoT enabled en-mass. People are much more open to making a configuration change if that is the least path of resistance.
[1] - https://dnsflagday.net/2019/
[1] - https://dnsflagday.net/2019/
This service is available from 2 companies; this services is available from 200,000 .. See they're exactly as centralised!!!one
Explain that to me?
Explain that to me?
DoH is just a protocol. DNS providers are adopting it as it is tested further and as it suits their needs or their customers'.
There are 40 publicly available servers listed on https://github.com/curl/curl/wiki/DNS-over-HTTPS from large and small players.
There are 40 publicly available servers listed on https://github.com/curl/curl/wiki/DNS-over-HTTPS from large and small players.
>> We invented DNSCrypt. There’s also DNS over TLS. Lots of ways to encrypt DNS without centralization.
Ummm so what’s the downside then? Are those services arcane and hard to use and utterly forbidding blackest black magic, like almost all crypto stuff?
If you’re thinking browser users will just do this then that then this and x and y and z to “get dns crypto going”, then I’ll take Mozilla’s “it just works” approach.
It’s a much much better approach for the browsers to implement it rather than wait for everyone’s operating system to implement secure dns because that’ll happen .... well I can’t imagine any time in the future you could say everyone’s OS is using crypto DNS, whereas if browsers implement it for themselves, instant massive adoption.
Ummm so what’s the downside then? Are those services arcane and hard to use and utterly forbidding blackest black magic, like almost all crypto stuff?
If you’re thinking browser users will just do this then that then this and x and y and z to “get dns crypto going”, then I’ll take Mozilla’s “it just works” approach.
It’s a much much better approach for the browsers to implement it rather than wait for everyone’s operating system to implement secure dns because that’ll happen .... well I can’t imagine any time in the future you could say everyone’s OS is using crypto DNS, whereas if browsers implement it for themselves, instant massive adoption.
Not sure what any of your reply means. Adding OS support isn’t required. People just run a local resolver that supports these things. No different than any other application. Nothing arcane. Certainly no more than HTTP and SSL.
I think you have some reading to do.
I think you have some reading to do.
>> People just run a local resolver that’s support’s these things.
Nowhere do “people just run a local resolver”. Grandma and aunty Beryl certainly don’t, nor does any other ordinary person. If you want secure DNS you have to build it in to the browser.
Only systems people think that this is the sort of thing that ordinary people do.
Nowhere do “people just run a local resolver”. Grandma and aunty Beryl certainly don’t, nor does any other ordinary person. If you want secure DNS you have to build it in to the browser.
Only systems people think that this is the sort of thing that ordinary people do.
Does Grandma have a small WiFi router that her cable modem is plugged into? Well that device provides local DNS for her.
Not true. In the default case, Grandma's wifi router is just passing along -- via DHCP -- the IP address of the cable company's DNS resolver to Grandma's computer. Which the wifi router itself probably obtained via DHCP or a similar mechanism from the modem. This is in no sense a "local DNS resolver."
If Grandma has a grandchild that knows how to set up a PiHole, it's a different story. But that's certainly not the majority of Grandmas or the majority of wifi routers.
If Grandma has a grandchild that knows how to set up a PiHole, it's a different story. But that's certainly not the majority of Grandmas or the majority of wifi routers.
I think the better solution is "build it into the browser and wait for systems to support it natively".
So exactly what Mozilla is doing.
>* People just run a local resolver that supports these things.*
How many people do you know that running local resolvers? How would this even work on Windows?
The world doesn’t need another encrypted dns solution that only works on Linux
How many people do you know that running local resolvers? How would this even work on Windows?
The world doesn’t need another encrypted dns solution that only works on Linux
How would this even work on iOS?
You write a network extension, which is what Cloudflare did for their 1.1.1.1 app.
You can literally do the same with DoH.
If you are a network administrator and want none of this, look at that:
https://support.mozilla.org/en-US/kb/canary-domain-use-appli...
Basically, make use-application-dns.net. return an error (any kind will do). Filter it in your recursor for example.
Having the browser change a fundamental behaviour that used to stand for decades is highly problematic. If nothing else, it is the network administrator who should have the final say on WHEN (if ever) DoH will get deployed inside their network.
https://support.mozilla.org/en-US/kb/canary-domain-use-appli...
Basically, make use-application-dns.net. return an error (any kind will do). Filter it in your recursor for example.
Having the browser change a fundamental behaviour that used to stand for decades is highly problematic. If nothing else, it is the network administrator who should have the final say on WHEN (if ever) DoH will get deployed inside their network.
>Having the browser change a fundamental behaviour that used to stand for decades is highly problematic.
No, this is far too broad of a statement. Browsers pushing for TLS, deprecating the old SSL versions and now the old TLS versions, deprecating SHA1 use in certificates, going from quirksmode to a living html standard (not without problems such as Google's over-influence), etc all have been a net positive, but there was breakage too.
Now, DNS - a really antiquated protocol written at a time when security played no role and everybody was assumed to be a good actor and (next to) nobody bought shit online or banked online or dated online or got medical advise online - is somehow the holy grail that MUST NEVER change? Because... "it works" (only superficially, without proper security) and status quo. I don't buy it.
We may discuss DNS and alternatives/add-ons (such as DoH, DoTLS, DNSSEC, DNSCrypt, etc) and their pros and cons, but rejecting any kind of innovation isn't something I am willing to do.
No, this is far too broad of a statement. Browsers pushing for TLS, deprecating the old SSL versions and now the old TLS versions, deprecating SHA1 use in certificates, going from quirksmode to a living html standard (not without problems such as Google's over-influence), etc all have been a net positive, but there was breakage too.
Now, DNS - a really antiquated protocol written at a time when security played no role and everybody was assumed to be a good actor and (next to) nobody bought shit online or banked online or dated online or got medical advise online - is somehow the holy grail that MUST NEVER change? Because... "it works" (only superficially, without proper security) and status quo. I don't buy it.
We may discuss DNS and alternatives/add-ons (such as DoH, DoTLS, DNSSEC, DNSCrypt, etc) and their pros and cons, but rejecting any kind of innovation isn't something I am willing to do.
> but rejecting any kind of innovation isn't something I am willing to do.
I don't think the post you're replying to is really saying "no innovation". I think it's more subtle.
The "problem" with DoH is that you need to look at it with several different hats, and I feel very few people make it clear how they're complaining about DoH.
* From a consumer perspective DoH is a good thing (mostly)
* From an traditional/enterprise/business-like environment perspective it's inserting itself in the middle of the stack and may cause headaches with a few things (not limited to leaking internal names to external resolvers), unless it's just blanket disabled/forced to a local server (which may not always be practical for different reasons) - currently
Ultimately who do we have to blame for this but ourselves? Organisations have tried to get encrypted DNS off the ground in traditional DNS infrastructure and clearly failed to meet the required timeline.
I personally feel like the problem, just like with IPv4, is that traditional DNS infrastructure is "fine" (i.e. it works). We don't have a great motivation but we do have fear of breaking the many many many boxes which are un-upgradeable/critical.
I don't think the post you're replying to is really saying "no innovation". I think it's more subtle.
The "problem" with DoH is that you need to look at it with several different hats, and I feel very few people make it clear how they're complaining about DoH.
* From a consumer perspective DoH is a good thing (mostly)
* From an traditional/enterprise/business-like environment perspective it's inserting itself in the middle of the stack and may cause headaches with a few things (not limited to leaking internal names to external resolvers), unless it's just blanket disabled/forced to a local server (which may not always be practical for different reasons) - currently
Ultimately who do we have to blame for this but ourselves? Organisations have tried to get encrypted DNS off the ground in traditional DNS infrastructure and clearly failed to meet the required timeline.
I personally feel like the problem, just like with IPv4, is that traditional DNS infrastructure is "fine" (i.e. it works). We don't have a great motivation but we do have fear of breaking the many many many boxes which are un-upgradeable/critical.
The elephant in the room is that many networks need to have content filtering, and you are proposing nothing useful. DoH torpedoes content filtering to its very core and, fortunately, the knob Mozilla provides can (hopefully) be utilized. That's all there's to it.
>The elephant in the room is that many networks need to have content filtering
First of all, we're talking about domain filtering, not content filtering.
And no, they want domain filtering, hardly anybody needs it, and there are better solutions than NXDOMAIN, such as actual content filters.
>and you are proposing nothing useful.
Why would I need to provide "something useful"? mozilla already described the many ways this can be disabled, from browser preferences, to automated checks for known disable-me domains, etc.
First of all, we're talking about domain filtering, not content filtering.
And no, they want domain filtering, hardly anybody needs it, and there are better solutions than NXDOMAIN, such as actual content filters.
>and you are proposing nothing useful.
Why would I need to provide "something useful"? mozilla already described the many ways this can be disabled, from browser preferences, to automated checks for known disable-me domains, etc.
I need domain filtering: if the domain serves malware I want to block it, not just the known malware coming from it. If a domain serves porn, I want to block it on my kids computers (and mine) not just the content that is recognisable as porn. If a domain is used by malware I want to block it, and probably use the domain to determine the server, and block that too (too because the domain can move IP).
All of that can be implemented on the client (e.g. as a browser extension) without breaking the Internet. That's the only reliable way to do it anyway. MITM DNS filtering is easily bypassed and only effective against lazy malware.
> If a domain serves porn, I want to block it on my kids computers (and mine)
FWIW, my entire peergroup grew up without anyone installing content filters on their computers, and porn was already widely available back then.
FWIW, my entire peergroup grew up without anyone installing content filters on their computers, and porn was already widely available back then.
This is quite a radical position, but there are no legitimate use cases for content filtering.
What use cases do people have in mind?
* State censorship. Totalitarian.
* "Parental controls". Child abuse. Learn how to build trust in your children instead.
* Corporate filtering. Find other ways to motivate your employees than blocking Facebook.
The problem with this implementation is that it doesn't go far enough. I want software to actively fight against the idea of content filtering.
What use cases do people have in mind?
* State censorship. Totalitarian.
* "Parental controls". Child abuse. Learn how to build trust in your children instead.
* Corporate filtering. Find other ways to motivate your employees than blocking Facebook.
The problem with this implementation is that it doesn't go far enough. I want software to actively fight against the idea of content filtering.
How about wanting to filter advertising, or filter content for myself - I block imgur via DNS for example, or block domains used by trackers and malware creators?
uBlock Origin works well. But you have a good point — you should be able to impose content filtering on yourself. And Firefox supports that.
This logic makes no sense to me. Can you imagine if AT&T or Spectrum made a statement like this?
The “network administrator” is an untrusted 3rd party who should have basically 0 say in how my device operates.
The device administrator, ie the owner of the machine, is the one who should have the final say over when DoH is used. The use-application-dns record is for businesses that want an easy way to stop DoH on machines they administer. If random “network admins” start deploying it as you say then Mozilla will have no choice but to ignore the record entirely.
The “network administrator” is an untrusted 3rd party who should have basically 0 say in how my device operates.
The device administrator, ie the owner of the machine, is the one who should have the final say over when DoH is used. The use-application-dns record is for businesses that want an easy way to stop DoH on machines they administer. If random “network admins” start deploying it as you say then Mozilla will have no choice but to ignore the record entirely.
So what if I run a Pihole at home as a DNS server and want to stop being able to resolve various domains? I would like to know how to stop all devices (actually worse, individual applications!) on my network deciding to DoH of their own accord (and therefore bypassing my local DNS server).
This kind of centralised ability to block DoH is very useful to me.
This kind of centralised ability to block DoH is very useful to me.
There are a couple use-cases here.
* On devices that you own and control you don't need a network level control like this except for convenience. This is when you should be applying the override record.
* On devices that you do not own or control (family/friends/guests) disabling DoH makes you the malicious network operator. Connecting to your Wi-Fi doesn't make you trusted in any sense of the word.
* On devices that you own but do not control (Google Home/Alexa) you make a valid point that techie types have been able to take some level of control by exploiting the fact that DNS is an unencrypted "hole" in the security of the device. You would have a lot more control if the HTTP traffic they sent was unencrypted and inspectable/modifiable but that doesn't mean devices shouldn't be allowed to use HTTPS without your approval.
* On devices that you own and control you don't need a network level control like this except for convenience. This is when you should be applying the override record.
* On devices that you do not own or control (family/friends/guests) disabling DoH makes you the malicious network operator. Connecting to your Wi-Fi doesn't make you trusted in any sense of the word.
* On devices that you own but do not control (Google Home/Alexa) you make a valid point that techie types have been able to take some level of control by exploiting the fact that DNS is an unencrypted "hole" in the security of the device. You would have a lot more control if the HTTP traffic they sent was unencrypted and inspectable/modifiable but that doesn't mean devices shouldn't be allowed to use HTTPS without your approval.
Thanks. Not to be argumentative, but I find it odd/interesting that guests connecting to my WiFi and using my DNS set up makes me a "malicious network operator" in your eyes. That's a very odd view of the world in my opinion, as it is my WiFi and DNS set up.
That's like saying that me stopping guests taking photos of my daily activities (showering, using the toilet) whilst in my house is a malicious behaviour too. I suppose I should let them post the photos off to whomever they choose?
If someone is in my house and using my WiFi, I don't want their device looking up domains that I choose to block. How do I know that their device is not recording its surroundings and sending them off to the said domain? How do I know that my guest is not up to nefarious/illegal activity using domains that I have blocked? I would be the one prosecuted due to the IP address = a person approach by the law in most circumstances (should they ever deduce the requested domains from the DoH set up). Being that the DoH provider is under law, I am pretty sure that the DoH will have to hand over any records they have, which will lead it back to me and my network.
And then once again we are stuck in a situation where I cannot control what domains are being looked up by devices and applications on my network. My devices are no longer mine. I have handed off control to some company the other side of the planet with employees I will never meet.
How do I stop the 5+ tracking domains that the Instagram app uses on my wife's iPhone, for example? Am I a malicious network operator for stopping that garbage being sent off?
That's like saying that me stopping guests taking photos of my daily activities (showering, using the toilet) whilst in my house is a malicious behaviour too. I suppose I should let them post the photos off to whomever they choose?
If someone is in my house and using my WiFi, I don't want their device looking up domains that I choose to block. How do I know that their device is not recording its surroundings and sending them off to the said domain? How do I know that my guest is not up to nefarious/illegal activity using domains that I have blocked? I would be the one prosecuted due to the IP address = a person approach by the law in most circumstances (should they ever deduce the requested domains from the DoH set up). Being that the DoH provider is under law, I am pretty sure that the DoH will have to hand over any records they have, which will lead it back to me and my network.
And then once again we are stuck in a situation where I cannot control what domains are being looked up by devices and applications on my network. My devices are no longer mine. I have handed off control to some company the other side of the planet with employees I will never meet.
How do I stop the 5+ tracking domains that the Instagram app uses on my wife's iPhone, for example? Am I a malicious network operator for stopping that garbage being sent off?
> I cannot control what domains are being looked up by devices and applications on my network.
This is kinda the point. For devices you own you have that control by the virtue of being the device admin. Other people's devices are a different story. You are free to have an acceptable use policy on your own network and require traffic to flow through a proxy or whatever but if you do it without their knowledge or consent you're the bad guy.
How pissed would you be if Xfinity just up and blocked random sites like this?
(sibebar: Just from a politeness perspective why would you give your guests anything other than a clean path to the public internet ?)
> That's like saying that me stopping guests taking photos of my daily activities
Having a rule that applies to your guests -- totally cool. Silently disabling their camera without their consent once they come through your door -- not cool.
> Am I a malicious network operator for stopping that garbage being sent off?
I mean you're modifying the traffic coming off of someone else's device without their knowledge or consent. I would be pissed if by husband did something like this without asking -- leaving me to debug why some sites are mysteriously broken.
This is kinda the point. For devices you own you have that control by the virtue of being the device admin. Other people's devices are a different story. You are free to have an acceptable use policy on your own network and require traffic to flow through a proxy or whatever but if you do it without their knowledge or consent you're the bad guy.
How pissed would you be if Xfinity just up and blocked random sites like this?
(sibebar: Just from a politeness perspective why would you give your guests anything other than a clean path to the public internet ?)
> That's like saying that me stopping guests taking photos of my daily activities
Having a rule that applies to your guests -- totally cool. Silently disabling their camera without their consent once they come through your door -- not cool.
> Am I a malicious network operator for stopping that garbage being sent off?
I mean you're modifying the traffic coming off of someone else's device without their knowledge or consent. I would be pissed if by husband did something like this without asking -- leaving me to debug why some sites are mysteriously broken.
If you can't trust your guests, then don't let them use your network.
You can attempt to block and filter things, but there will always be a way for something malicious to bypass it.
You can attempt to block and filter things, but there will always be a way for something malicious to bypass it.
I'm _maliciously_ stopping my kids Android apps from connecting to tracking and malware domains. What a tyrant I am - I should have over control to a third-party for profit company??!?
You're kidding, right.
You're kidding, right.
You own and control your child's phone. You're in case #1. Family is meant to mean your spouse, adult children, or relatives.
Of note: PiHole supports DoH, so you point your DoH supporting applications at it. If your OS gets around to adding DoH support you can point your entire OS at it and disable DoH in applications, but until then you'll have to do things the hard way.
At present though devices on the network all for DNS and my network says "use pihole" but applications that implement DoH never ask the network, so I have to have access to all the applications (including those from bad actors).
I block MS telemetry domains for example, where's the config for me to stop them using DoH; what about the trackers on my TV?
Now I need to configure every device - that's capable of using Firefox - rather than configuring the network. Presumably in short shrift there'll be no way to block Google advertising. I guess Google will get their return on funding Firefox.
I block MS telemetry domains for example, where's the config for me to stop them using DoH; what about the trackers on my TV?
Now I need to configure every device - that's capable of using Firefox - rather than configuring the network. Presumably in short shrift there'll be no way to block Google advertising. I guess Google will get their return on funding Firefox.
Not apply the same logic to a network-wide ad-blocking HTTP filter and HTTPS.
AT&T and Spectrum do not administer your home network, you do. You have the freedom to configure whatever DNS settings you want; if you wish to use their DNS servers you may; if you wish not to, then you may not.
DoH is a non-solution to a non-problem which makes privacy strictly worse by leaking information to Cloudflare in addition to one's ISP.
DoH is a non-solution to a non-problem which makes privacy strictly worse by leaking information to Cloudflare in addition to one's ISP.
You are a client on AT&T and Spectrum's network. Just because you turn on a router and set up NAT doesn't make this fact any less true. At some point your internet traffic is going to flow AT&T's network where they are the administrators and are free to apply whatever network policy they see fit.
DoH and DoT is a solution to the problem of sending your DNS requests unencrypted, leaking them to everyone in the process, and then opening the door to any malicious network operator in between you and your DNS server the ability to modify the response in-flight.
Your ISP can and should provide DoH servers. Your local network is free to do the same.
DoH and DoT is a solution to the problem of sending your DNS requests unencrypted, leaking them to everyone in the process, and then opening the door to any malicious network operator in between you and your DNS server the ability to modify the response in-flight.
Your ISP can and should provide DoH servers. Your local network is free to do the same.
I agree with you: your local network is free to set up a resolver using DoH (or DoT, which is far more sane than an entire HTTPS connexion). That's the correct place for it to live, or possibly at the individual device level.
It is 100% not the place of an application to meddle with network services, particularly not by default.
It is 100% not the place of an application to meddle with network services, particularly not by default.
How dare an application use a socket to make a network request using an application layer protocol for its own use.
Has anyone verified that this actually works? My company's DNS administrators have already made this change. use-application-dns.net returns SERVFAIL when I run "dig" on my machine on the corporate network.
But if I enable DNS over HTTPS in Firefox, it very clearly still uses the Cloudflare resolvers. We have some split-horizon zones set up (resolve to 10.x IP's internally, and public IP's externally). When I tick the DoH box, Firefox starts resolving the public IP, verified in the Dev Tools network pane.
Curious if the issue lies with us or Mozilla.
But if I enable DNS over HTTPS in Firefox, it very clearly still uses the Cloudflare resolvers. We have some split-horizon zones set up (resolve to 10.x IP's internally, and public IP's externally). When I tick the DoH box, Firefox starts resolving the public IP, verified in the Dev Tools network pane.
Curious if the issue lies with us or Mozilla.
If you did it explicitly, I think there are no heuristics.
https://bugzilla.mozilla.org/show_bug.cgi?id=1614751
https://bugzilla.mozilla.org/show_bug.cgi?id=1614751
I'd guess that the overwhelming majority of Mozilla's users do not have a "network administrator" looking after issues like this for them. All they have is an ISP, and the ISP is not on the user's side.
Everyone who uses DNS-based content filtering (OpenDNS, a "Pi Hole", etc) to do filtering on a home network is a "network administrator".
Care to guess what percentage of Mozilla's users are included in that group? The HN crowd is far from being a typical sample.
My point is that the definition of "network administrator" is wider than the corporate network administrator vision the phrase evokes.
A quick search shows me a number of parental control features in routers that use OpenDNS. All of the parents using those features would be "network administrators", too.
I think more people are "network administrators" than the average HN reader realizes.
A quick search shows me a number of parental control features in routers that use OpenDNS. All of the parents using those features would be "network administrators", too.
I think more people are "network administrators" than the average HN reader realizes.
The ISPs can easily be swapped out, they're was much on the client side as Cloudflare, probably more so.
I wonder if we’ll start to see Comcast and other large snooping ISPs start to filter the resolution of this domain in the name of stability...
If they do that, Mozilla will probably immediately update the check or remove it all together.
I don't understand why systems administrators don't just use their existing policy management to disable DoH if it really causes an issue. There's a group policy specifically for DNS over HTTPS [1]
The only reason I can think of is that they can't because of BYOD or Firefox being part of the company's dark IT. The DNS workaround doesn't help much in those cases because the underlying problem is a lack of oversight, not an issue with Firefox.
[1] https://github.com/mozilla/policy-templates/blob/master/READ...
I don't understand why systems administrators don't just use their existing policy management to disable DoH if it really causes an issue. There's a group policy specifically for DNS over HTTPS [1]
The only reason I can think of is that they can't because of BYOD or Firefox being part of the company's dark IT. The DNS workaround doesn't help much in those cases because the underlying problem is a lack of oversight, not an issue with Firefox.
[1] https://github.com/mozilla/policy-templates/blob/master/READ...
Can't imagine that will last for long. Otherwise what stops Telcos/ISPs blocking this in their resolvers.
My feeling on this is that it's a pretty imperfect solution but unsurprising that the browser manufacturers are pushing it forward given ISPs dragging their heels on DoT.
We saw the same problem with TLS. Until the browser makers started pushing it and Let's encrypt made it simple/free the take up of TLS was patchy at best.
This will have negative effects on tools that use DNS for blocking/monitoring, but then those were a hack at best. If you want to understand the traffic flowing over your network, you need to invest in interception and parsing.
We saw the same problem with TLS. Until the browser makers started pushing it and Let's encrypt made it simple/free the take up of TLS was patchy at best.
This will have negative effects on tools that use DNS for blocking/monitoring, but then those were a hack at best. If you want to understand the traffic flowing over your network, you need to invest in interception and parsing.
> ISPs dragging their heels on DoT
WTH does DoT adoption by ISPs have to do with that?!
One can run their own DNS recursive resolver-cache perfectly fine on their own hosts, or at the network edge, without relying on ISPs.
Better yet: Since the Root zone and TLD zone DNS servers change only seldomly, you can prefetch and cache them locally just fine, and upon resolving a DNS skip two recursion steps.
Apart from doing DPS, then ISPs will not "see" DNS queries, thus bypassing the privacy concerns of that.
WTH does DoT adoption by ISPs have to do with that?!
One can run their own DNS recursive resolver-cache perfectly fine on their own hosts, or at the network edge, without relying on ISPs.
Better yet: Since the Root zone and TLD zone DNS servers change only seldomly, you can prefetch and cache them locally just fine, and upon resolving a DNS skip two recursion steps.
Apart from doing DPS, then ISPs will not "see" DNS queries, thus bypassing the privacy concerns of that.
Most end users don't just "run their own recursive resolver-cache" They take whatever DNS server is provided by their ISP
I'd guess that 99+% of Internet users have no idea how to run their own DNS server, let alone set up DoT.
I'd guess that 99+% of Internet users have no idea how to run their own DNS server, let alone set up DoT.
That's not a good counterargument. Why you ask? Because that's something that OS vendors could easily and trivially deploy with only minimal effort.
For example on Linux you could do this with running a localhost instance of unbound, and having a DHCP client hook script updating unbound's configuration for domain specific authorative DNS servers based on the DHCP options for nameserver and domain name.
Just put that as out-of-the-box setup into default Linux distributions' installation: Not only does this greatly enhance privacy. It also prevents enterprise information leakage, and every program on the system is going to benefit from it. Not just the browser.
DoH is a clusterfuck of stupid. There's not one single redeeming quality about it. Everything positive it promises to do has been already solved in a far better manner by earlier developments. And it comes with the penality of concentration of failure points.
In the best case scenario it doesn't impair your privacy.
In the worst case scenario, all the DoH resolver operators in the U.S. will get FISA court orders – including a gag order – to install boxes helpfully provided by some three-letter-agency that monitor all incoming and outgoing traffic of their resolvers; getting the DNS queries/responses in the clear would be nice, but they don't really need it, for the resolvers provide some nicely observable traffic hub on where it's super easy to time correlate outgoing DNS resolver queries to incoming DoH requests.
And don't even believe that DoH requests would be indistinguishable from "regular" HTTPS traffic! Unless you're running into an DNS record that's been overloaded with everything DNSSEC offers the bandwidth requirements of DNS are fairly balanced in both directions. Plus, the amount of data transferred via DoH is more or less the net size of the final DNS query and request combined. So either you pad DoH for the worst case scenario size, or you have a pretty well readable side channel.
No matter from which angle you look at it, DoH makes no fucking sense whatsoever. It's just stupid, if not malicious.
For example on Linux you could do this with running a localhost instance of unbound, and having a DHCP client hook script updating unbound's configuration for domain specific authorative DNS servers based on the DHCP options for nameserver and domain name.
Just put that as out-of-the-box setup into default Linux distributions' installation: Not only does this greatly enhance privacy. It also prevents enterprise information leakage, and every program on the system is going to benefit from it. Not just the browser.
DoH is a clusterfuck of stupid. There's not one single redeeming quality about it. Everything positive it promises to do has been already solved in a far better manner by earlier developments. And it comes with the penality of concentration of failure points.
In the best case scenario it doesn't impair your privacy.
In the worst case scenario, all the DoH resolver operators in the U.S. will get FISA court orders – including a gag order – to install boxes helpfully provided by some three-letter-agency that monitor all incoming and outgoing traffic of their resolvers; getting the DNS queries/responses in the clear would be nice, but they don't really need it, for the resolvers provide some nicely observable traffic hub on where it's super easy to time correlate outgoing DNS resolver queries to incoming DoH requests.
And don't even believe that DoH requests would be indistinguishable from "regular" HTTPS traffic! Unless you're running into an DNS record that's been overloaded with everything DNSSEC offers the bandwidth requirements of DNS are fairly balanced in both directions. Plus, the amount of data transferred via DoH is more or less the net size of the final DNS query and request combined. So either you pad DoH for the worst case scenario size, or you have a pretty well readable side channel.
No matter from which angle you look at it, DoH makes no fucking sense whatsoever. It's just stupid, if not malicious.
I like how someone on HN tells you that ordinary users have no idea how to set up their own DNS servers and you respond with how Linux users can set up unbound. Like, well argued!
There is also something poetic about how the people that know how and are inclined to set up their own unbound servers on their laptops are getting worse security than everyone else. That sparks joy for me.
There is also something poetic about how the people that know how and are inclined to set up their own unbound servers on their laptops are getting worse security than everyone else. That sparks joy for me.
> you respond with how Linux users can set up unbound. Like, well argued!
I did write, that DISTRIBUTIONS should set this up by default, not the users.
And Microsoft could do the same for Windows, as could Apple (with almost zero effort) for MacOS-X
I did write, that DISTRIBUTIONS should set this up by default, not the users.
And Microsoft could do the same for Windows, as could Apple (with almost zero effort) for MacOS-X
>For example on Linux you could do this with running a localhost instance of unbound
Not seeing _distributions_ there
Not seeing _distributions_ there
Look again. Topmost paragraph. I'll quote myself:
>> Because that's something that OS vendors could easily and trivially deploy with only minimal effort.
"OS vendors" aka "distribution creators"
And then in the 3rd paragraph, I wrote (sic!):
>> Just put that as out-of-the-box setup into default Linux distributions' installation:
>> Because that's something that OS vendors could easily and trivially deploy with only minimal effort.
"OS vendors" aka "distribution creators"
And then in the 3rd paragraph, I wrote (sic!):
>> Just put that as out-of-the-box setup into default Linux distributions' installation:
> WTH does DoT adoption by ISPs have to do with that?!
The ISPs need to support DoT server-side, at their end?
The ISPs need to support DoT server-side, at their end?
> The ISPs need to support DoT server-side, at their end?
That's not how DNS works.
Just put DoT capable cachine-resolvers onto each host, and you're golden. Those to even play nicely with enterprise infrastructure, like a local DNS.
That's not how DNS works.
Just put DoT capable cachine-resolvers onto each host, and you're golden. Those to even play nicely with enterprise infrastructure, like a local DNS.
The underlying issue is that a DoH provider can craft the DNS answers individual users get if it wants to.
Think about it: a Firefox DoH user could get different DNS answers than other apps get on the same machine using standard DNS on port 53, if Google or Cloudflare wanted to, because they’re essentially talking to different versions of the internet.
Remember, all of the properties that allows HTTPS to be trackable—cookies, fingerprinting and the rest—is in play for DNS over HTTPS as well. DoT doesn’t allow for that.
If all these providers wanted was encrypted DNS, they’d be pushing DNS over TLS, which is just standard DNS using TLS as the transport. Sure, it uses port 853, but given time, enterprises and other security-conscious organizations would have adjusted, especially if the entire DNS ecosystem got behind it.
But because Google, Cloudflare and NextDNS see an opportunity of some kind, they are pushing for DoH.
The DNS is an open, global, distributed hierarchical database; DoH starts to break this because apps can bypass most of this and that’s not how the internet was designed to work.
The same way Gmail broke the model of federated SMTP servers to a large extent, there’s the potential for the major DoH providers to do the same to DNS.
Imagine if Cloudflare decided to block certain DNS records from their users. Certain services that worked fine pre-DoH would break.
Take a look at the article DNS Wars; it’s eye opening: https://blog.apnic.net/2019/11/04/dns-wars/
Think about it: a Firefox DoH user could get different DNS answers than other apps get on the same machine using standard DNS on port 53, if Google or Cloudflare wanted to, because they’re essentially talking to different versions of the internet.
Remember, all of the properties that allows HTTPS to be trackable—cookies, fingerprinting and the rest—is in play for DNS over HTTPS as well. DoT doesn’t allow for that.
If all these providers wanted was encrypted DNS, they’d be pushing DNS over TLS, which is just standard DNS using TLS as the transport. Sure, it uses port 853, but given time, enterprises and other security-conscious organizations would have adjusted, especially if the entire DNS ecosystem got behind it.
But because Google, Cloudflare and NextDNS see an opportunity of some kind, they are pushing for DoH.
The DNS is an open, global, distributed hierarchical database; DoH starts to break this because apps can bypass most of this and that’s not how the internet was designed to work.
The same way Gmail broke the model of federated SMTP servers to a large extent, there’s the potential for the major DoH providers to do the same to DNS.
Imagine if Cloudflare decided to block certain DNS records from their users. Certain services that worked fine pre-DoH would break.
Take a look at the article DNS Wars; it’s eye opening: https://blog.apnic.net/2019/11/04/dns-wars/
> Think about it: a Firefox DoH user could get different DNS answers than other apps get on the same machine using standard DNS on port 53, if Google or Cloudflare wanted to, because they’re essentially talking to different versions of the internet.
How is that different than existing DNS servers?
How is that different than existing DNS servers?
How is that different than existing DNS servers?
Because standard DNS servers using mostly UDP can’t track you the way a DoH server can.
The more centralized DoH becomes, the more tempting it’ll be to monetize that traffic.
Because standard DNS servers using mostly UDP can’t track you the way a DoH server can.
The more centralized DoH becomes, the more tempting it’ll be to monetize that traffic.
There's no difference that a DNS server can see between a browser on your computer making a DNS request vs. any other app. But if the browser is using DoH and other apps don't, then it can tell.
Right, but that's just an argument for more applications and lower level networking stacks to support DoH.
Not really. It's an argument for the industry moving to something sensible; not "split braining" low level infrastructure by shoehorning some of it into HTTP, apps and a handful of centralised coporations who claim to play a little nicer than telcos.
[deleted]
I posted the article Centralised DoH is bad for Privacy, in 2019 and beyond to HN nearly a week ago [1].
Here’s the money quote:
DNS over HTTPS however neatly separates out each device (and even each individual application on that device) to a separate query stream. This alone is worrying, as we now have individual users’ queries, but the TLS that underlies HTTPS also typically uses TLS Resumption which offers even further tracking capabilities.
[1]: https://news.ycombinator.com/item?id=22362864
Here’s the money quote:
DNS over HTTPS however neatly separates out each device (and even each individual application on that device) to a separate query stream. This alone is worrying, as we now have individual users’ queries, but the TLS that underlies HTTPS also typically uses TLS Resumption which offers even further tracking capabilities.
[1]: https://news.ycombinator.com/item?id=22362864
Yes, in the hypothetical case that some agency is compelling CloudFlare (and/or NextDNS) to provide ongoing real-time decryption, which would be somewhat unprecedented: not entirely dissimilar to things which have been publicly reported before, but not the same either. In the more likely case that that isn't happening, you make those agencies' lives a lot harder.
> Cloudflare does not block or filter content through the Cloudflare Resolver for Firefox. As part of its agreement with Mozilla, Cloudflare is providing only direct DNS resolution. If Cloudflare were to receive written requests from law enforcement and government agencies to block access to domains or content through the Cloudflare resolver for Firefox, Cloudflare would, in consultation with Mozilla, exhaust our legal remedies before complying with such a request. We also commit to documenting any government request to block access in our semi-annual transparency report, unless legally prohibited from doing so.
https://developers.cloudflare.com/1.1.1.1/commitment-to-priv....
What DoH implementation sends cookies?
They all can; that’s built in to HTTPS. Whether they will, we’ll have to wait and see.
Normal DNS over UDP can also contain arbitrary data, which completely hypothetcally could be used to send identifying data about the client. E.g. https://unit42.paloaltonetworks.com/dns-tunneling-how-dns-ca... But that's not really a strike against the protocol, that would be a fault of the implementation.
In order for Cloudflare (or anyone) to be a part of this program they have to comply with a particular set of rules.
Limiting data. Your DNS data can reveal a lot of sensitive information about you, and currently DNS providers aren’t subject to any limits on what they can do with that data; we want to change that. Our policy requires that your data will only be used for the purpose of operating the service, must not be retained for longer than 24 hours, and cannot be sold, shared, or licensed to other parties.
Yes, governments can secret around this with intelligence orders, just like they can do with any of the ISPs that will keep all of the data indefinitely instead of for 24 hours.
Limiting data. Your DNS data can reveal a lot of sensitive information about you, and currently DNS providers aren’t subject to any limits on what they can do with that data; we want to change that. Our policy requires that your data will only be used for the purpose of operating the service, must not be retained for longer than 24 hours, and cannot be sold, shared, or licensed to other parties.
Yes, governments can secret around this with intelligence orders, just like they can do with any of the ISPs that will keep all of the data indefinitely instead of for 24 hours.
> just like they can do with any of the ISPs
There is a 3rd option: Operating your own recursive resolver.
There is a 3rd option: Operating your own recursive resolver.
I've found this harder and harder over the years. My usual MOD was installing and configuring the caching-nameserver BIND package in rpm-based RHEL-downstream distros and MaraDNS in everything else. I've just kind of given up because reasons but I'm still very supportive of any of these kinds of efforts.
unbound is much easier to configure than BIND in my experience
Doesn't that just move the problem one step away?
It removes a 3rd party that is a juicy target for TLAs. There is only you and the remote hosts that you're talking to.
But yes, it would be really nice if we also had encryption between recursive resolvers and authoritative servers to remove the last place where they could harvest data.
But yes, it would be really nice if we also had encryption between recursive resolvers and authoritative servers to remove the last place where they could harvest data.
Kind of sad when you need a private company to give your citizens the basic privacy they want (doubly so when you have to simply trust said company that the partners they are working with are honest). Maybe the US's privacy laws need a 21st Century make over?
Why are people so down on DNS over HTTPS?
DNS is the primary way governments control and spy on web access.
DNS is the primary way governments control and spy on web access.
I think part of the negativity you see is network admins working in businesses.
Their opinion is that it's a way for people to get around corporate firewalls. Kinda blind to the idea that if a browser can implement DNS over HTTPS then anything can.
Especially since there's some of ways that Mozilla have implemented for a local area DNS server to override its settings.
There's also another camp, if you remember the "internet villain of the year" award that Mozilla got for DNS over HTTPS from an ISP industry group.
Of course their argument was parental controls being made ineffective.
But of course it's transparent that this was a gambit to change public opinion so they can keep collecting browsing data to sell.
Interesting to note they went after Mozilla not Google who are also implementing it.
But really the messed up thing is that this improves privacy for the vast majority of users. Especially those people around the world where searching the wrong thing up online can lead to imprisonment or worse.
This kind of thing is a privacy improvement for millions.
And I find it shocking that people in Business IT care more about managing their corporate devices than the good of the majority of internet users.
Their opinion is that it's a way for people to get around corporate firewalls. Kinda blind to the idea that if a browser can implement DNS over HTTPS then anything can.
Especially since there's some of ways that Mozilla have implemented for a local area DNS server to override its settings.
There's also another camp, if you remember the "internet villain of the year" award that Mozilla got for DNS over HTTPS from an ISP industry group.
Of course their argument was parental controls being made ineffective.
But of course it's transparent that this was a gambit to change public opinion so they can keep collecting browsing data to sell.
Interesting to note they went after Mozilla not Google who are also implementing it.
But really the messed up thing is that this improves privacy for the vast majority of users. Especially those people around the world where searching the wrong thing up online can lead to imprisonment or worse.
This kind of thing is a privacy improvement for millions.
And I find it shocking that people in Business IT care more about managing their corporate devices than the good of the majority of internet users.
I'm not a network admin working in a business, but I am the network admin of my home network, and I really do not want applications starting to effectively contain their own VPN clients and subverting my control.
DNS isn't a VPN nor really a security product. It's just a look up table.
The job blocking domains should be the job of a firewall. Of course this becomes more complex. But any application can implement DNS over HTTPS.
Malware could even just get a list of IPs from another IP.
An application can even just hard code IPs rather than using DNS and then they're in the same position.
The job blocking domains should be the job of a firewall. Of course this becomes more complex. But any application can implement DNS over HTTPS.
Malware could even just get a list of IPs from another IP.
An application can even just hard code IPs rather than using DNS and then they're in the same position.
Tunneling DNS inside HTTPS effectively forms part of a VPN already (and I wonder when Mozilla will decide to also stuff the rest of the traffic through...)
DNS-based blocking is not perfect, but is currently still very powerful for things like adblocking.
You're basically saying that Firefox is now behaving like malware, which I agree with...
Windows 10's telemetry is also another piece of software which has started to become hostile in this manner, hardcoding IPs and such.
DNS-based blocking is not perfect, but is currently still very powerful for things like adblocking.
You're basically saying that Firefox is now behaving like malware, which I agree with...
Windows 10's telemetry is also another piece of software which has started to become hostile in this manner, hardcoding IPs and such.
Exactly. To control DoH we need to start to MITM all connections and block everthing else unless whitelisted.
For home network operators who value controlling the name resolution of devices they 'own' MITM won't be enough once embedded device manufacturers start using certificate pinning w/ DoH.
Obviously, there will be a choice not to buy them / keep them offline.
> I wonder when Mozilla will decide to also stuff the rest of the traffic through
Mozilla has recently begun offering an integrated VPN with Firefox, though unlike DoH that has a monthly subscription fee (hell, I don't blame them for wanting to diversify their revenue). The partner in that case is Mullvad.
> You're basically saying that Firefox is now behaving like malware
This is hyperbole. End users should look out for their own best interests by using any means necessary, which includes hiding as much as they can from the network. If the network doesn't like that, then it has the choice not to allow that user to attach a device to the network.
Mozilla has recently begun offering an integrated VPN with Firefox, though unlike DoH that has a monthly subscription fee (hell, I don't blame them for wanting to diversify their revenue). The partner in that case is Mullvad.
> You're basically saying that Firefox is now behaving like malware
This is hyperbole. End users should look out for their own best interests by using any means necessary, which includes hiding as much as they can from the network. If the network doesn't like that, then it has the choice not to allow that user to attach a device to the network.
It's the inherent problem of your network position being between a device and the outside internet, the same position that browser activity-selling, website blocking ISPs are. The only difference is that previously, DNS would be unencrypted so you could DPI dns and/or block DNS requests going outside of your custom resolver. If an attacker wanted to hide DNS previously, they would need a hard-coded IP address to send encrypted requests to; now they can use big providers like CF/Google for DoH.
If you don't want DoH, you are not forced to use it. Yes its enabled by default, but it doesn't mean you cannot go into the settings menu and deactivate it.
Hmm, unless you're trying to control what comes in/out your home network .. in which case you're screwed. But you can switch it off in your own browser.
I was a happy pihole user. I could choose to allow DNS lookups, and blacklist using OpenDNS. If I install Firefox at home, then I can't block problematic sites; and Cloudflare will use this to sell the idea to advertiser for TVs and such, so it looks like Google/Cloudflare just used Firefox to obviate ad blocking.
I was a happy pihole user. I could choose to allow DNS lookups, and blacklist using OpenDNS. If I install Firefox at home, then I can't block problematic sites; and Cloudflare will use this to sell the idea to advertiser for TVs and such, so it looks like Google/Cloudflare just used Firefox to obviate ad blocking.
I also use PiHole at home, and lets be honest, if we know how to setup a PiHole, deactivating Firefox DoH is not going to be a problem for us.
DoH is not meant for us, it is meant for the average people who have no tech background. Just because it will cost us a few minutes to configure, we shouldn't deny the overall benefit it will bring to most.
DoH is not meant for us, it is meant for the average people who have no tech background. Just because it will cost us a few minutes to configure, we shouldn't deny the overall benefit it will bring to most.
> Their opinion is that it's a way for people to get around corporate firewalls. Kinda blind to the idea that if a browser can implement DNS over HTTPS then anything can.
Thats not the problem. If more application folow Firefox, and do DNS on their own, corporate applications and sites will stop working, and IT will get the blame.
Now that it's just firefox, ok, but if other app will follow the lead, we will constantly have to play whack a mole, why someone doesn't resolve correctly.
How do I debug problems ?
Is there a tool (something like dig), i can use to see, how will Firefox resolve a domain ?
Where i work we don't block anything on our firewall, but we have plenty of services only exposed on internal DNS. Not to mention, we have to a lot of times replicate environment that is similar to clients, so I often create zones, where people can VPN in, and have similar DNS resolution as the target. Each app doing its own DNS will make that harder.
> Especially those people around the world where searching the wrong thing up online can lead to imprisonment or worse
That would be true, if Mozilla rolled this out worldwide, but its US only.
Also right now there are bazillion ISP with bazillion DNS servers.
There are very few DOH DNS providers that Mozilla endorses, so if majority of "privacy" conscious people will start using them, it will become that more valuable for various bad actors to compromise them. Right now there are so many ISP's with their own DNS's that even if all of them were selling the data, just finding them all and buying their data would be huge task.
This is another centralization of previously decentralized service. (like it happened with email)
Honestly I think that in the long run, this will be worse for privacy that we have now.
Thats not the problem. If more application folow Firefox, and do DNS on their own, corporate applications and sites will stop working, and IT will get the blame.
Now that it's just firefox, ok, but if other app will follow the lead, we will constantly have to play whack a mole, why someone doesn't resolve correctly.
How do I debug problems ?
Is there a tool (something like dig), i can use to see, how will Firefox resolve a domain ?
Where i work we don't block anything on our firewall, but we have plenty of services only exposed on internal DNS. Not to mention, we have to a lot of times replicate environment that is similar to clients, so I often create zones, where people can VPN in, and have similar DNS resolution as the target. Each app doing its own DNS will make that harder.
> Especially those people around the world where searching the wrong thing up online can lead to imprisonment or worse
That would be true, if Mozilla rolled this out worldwide, but its US only.
Also right now there are bazillion ISP with bazillion DNS servers.
There are very few DOH DNS providers that Mozilla endorses, so if majority of "privacy" conscious people will start using them, it will become that more valuable for various bad actors to compromise them. Right now there are so many ISP's with their own DNS's that even if all of them were selling the data, just finding them all and buying their data would be huge task.
This is another centralization of previously decentralized service. (like it happened with email)
Honestly I think that in the long run, this will be worse for privacy that we have now.
> I think part of the negativity you see is network admins working in businesses.
They can block the canary domain[1].
> Of course their argument was parental controls being made ineffective.
DoH is disabled on Windows and macOS if parental controls are enabled[1].
[1] https://support.mozilla.org/en-US/kb/configuring-networks-di...
They can block the canary domain[1].
> Of course their argument was parental controls being made ineffective.
DoH is disabled on Windows and macOS if parental controls are enabled[1].
[1] https://support.mozilla.org/en-US/kb/configuring-networks-di...
My main gripe is that before DoH, setting a custom DNS via DHCP was enough to get all devices on a network and all applications on these devices to use a custom DNS.
Now we are headed to a future where each software vendor decides how to make DNS queries. I can predict that all of them will apply their own custom heuristics to detect things like split-horizon.
Now we are headed to a future where each software vendor decides how to make DNS queries. I can predict that all of them will apply their own custom heuristics to detect things like split-horizon.
> before DoH, setting a custom DNS via DHCP was enough
That ship had already sailed. You also have to run your own DNS, allow DNS egress only from your own DNS, and DNAT the rest back to yours in order to un-break all the things with hard-coded resolvers.
That ship had already sailed. You also have to run your own DNS, allow DNS egress only from your own DNS, and DNAT the rest back to yours in order to un-break all the things with hard-coded resolvers.
Same with NTP surprisingly. Literally everything I have talks to a NTP server once in a while, but only Linux machines actually ask the network's NTP servers.
Lots of embedded Linux devices have hardcoded NTP servers. Was caught by surprise at this after I'd segregated a bunch of stuff to have no Internet access.
Absolutely, but I found it surprising that even my Kindle contacts an NTP server, or that both Android and Apple phones do.
Why don't they ask DHCP for a nice stratum 1 server instead, I don't know, maybe someone here does?
Why don't they ask DHCP for a nice stratum 1 server instead, I don't know, maybe someone here does?
We are headed toward that future because the broader network has proven that it cannot be trusted; it should come as no surprise that user agents would develop defense mechanisms. If this is another step toward ensuring that ISPs are nothing but dumb pipes, I welcome it.
This is another step toward ensuring that _you_ won't have any visibility what applications running on your computer do, where they connect and why.
Unless OSs quickly implement DoH, if they did, software makers won't have any excuse to roll their own opaque ones, aside of malicious reasons.
End-to-end TLS is dead.
It started with PCI compliance. Next up was Corporate IT making sure idiots weren't signing up for Dropbox with their LAN password. Schools: Well, they always used proxies with no expectation of privacy whatsoever so traffic inspection was nothing new.
In 5 years TLS-recryption -- whether through software or a hardware middlebox -- will be as ubiquitous as a NAT firewall is now. The only question is if the keys will be in the hands of the consumer or in escrow with Big Gov.
The idea that anyone in their right mind would allow uninspectable traffic to egress their network is beyond ridiculous. I'm glad that DoH is making people realize that.
It started with PCI compliance. Next up was Corporate IT making sure idiots weren't signing up for Dropbox with their LAN password. Schools: Well, they always used proxies with no expectation of privacy whatsoever so traffic inspection was nothing new.
In 5 years TLS-recryption -- whether through software or a hardware middlebox -- will be as ubiquitous as a NAT firewall is now. The only question is if the keys will be in the hands of the consumer or in escrow with Big Gov.
The idea that anyone in their right mind would allow uninspectable traffic to egress their network is beyond ridiculous. I'm glad that DoH is making people realize that.
The problem I have with DNS over HTTPS is that it's something implemented in the browser, that ignores the DNS configuration of your PC and your local network. That has some implication, for example you are unable to access local hosts on your network by their hostname (for example https://fileserver). Also you have a solution that works only on one program, while the rest of the system DNS requests remain unencrypted, that is bad.
Browsers shouldn't implement DNS theirself, and should use operating system APIs to do all the DNS queries. That is how networks work, and doing that differently creates problems (imagine if every program has its implementation of DNS over HTTPS, you have to configure correctly the DNS server in each of them, and good luck debugging it when one implementation is broken...)
As a technical motivation, HTTPS in an high level protocol, and using it for DNS is kind an overhead. We already have DNS over TLS that is a standadized protocol, that can be used, and that the operating systems are starting to implement.
I use DNS over TLS in my local network, but rather than having configured all the computers to use it I have configured a local DNS server that encrypts the requests, for every host in the network, and also filters trackers and ad servers. Thus I don't want Firefox to mess aroung with my local network configuration that is fine.
Browsers shouldn't implement DNS theirself, and should use operating system APIs to do all the DNS queries. That is how networks work, and doing that differently creates problems (imagine if every program has its implementation of DNS over HTTPS, you have to configure correctly the DNS server in each of them, and good luck debugging it when one implementation is broken...)
As a technical motivation, HTTPS in an high level protocol, and using it for DNS is kind an overhead. We already have DNS over TLS that is a standadized protocol, that can be used, and that the operating systems are starting to implement.
I use DNS over TLS in my local network, but rather than having configured all the computers to use it I have configured a local DNS server that encrypts the requests, for every host in the network, and also filters trackers and ad servers. Thus I don't want Firefox to mess aroung with my local network configuration that is fine.
For one, it’s ironically first being deployed in countries where DNS manipulation by the government isn’t happening (US first generally), but Google has competitive concerns with ISPs getting ad targeting data. I feel like defending against oppressive governments is being used more as an excuse than a driving motivation. The primary concern seems to be that Google really wants to protect its monopoly, and Firefox, as a major benefactor of Google money, has fallen in line.
And second, as an IT admin, I’m annoyed web browsers keep trying to develop new ways to bypass my network security.
And second, as an IT admin, I’m annoyed web browsers keep trying to develop new ways to bypass my network security.
Decades of experience have told me that whenever some big organisation wants to do something in the name of "security", it's almost always an excuse to remove freedom and force their control over everyone.
Yes, that includes oppressive governments too... but I hardly think that even more centralisation is the solution.
The old security vs freedom quote is surprisingly relevant in so many situations today.
Yes, that includes oppressive governments too... but I hardly think that even more centralisation is the solution.
The old security vs freedom quote is surprisingly relevant in so many situations today.
This argument can be applied to the encouraging the rollout of HSTS and HTTPS by firefox and google, which cant be disabled very easily by administrators.
And now they have a one-stop shop for all their DNS surveillance needs.
> And now they have a one-stop shop for all their DNS surveillance needs.
There are a few dozens of DoH services out there [1] and nothing prevents anybody else from running their own.
[1] https://github.com/curl/curl/wiki/DNS-over-HTTPS
There are a few dozens of DoH services out there [1] and nothing prevents anybody else from running their own.
[1] https://github.com/curl/curl/wiki/DNS-over-HTTPS
But Mozilla's justification tables around making security better for all users by dictating default settings that are expected not to change. So, defaults need to achieve the goals.
How many of those "dozens" would you consider usable as a default for a browser?
There are dozens, and yet Mozilla chooses the same company that forces Google captcha on site visitors that try to protect their privacy by using a VPN or Tor?
Well it’s absolutely happening right now to every unencrypted DNS server, so what’s your point?
DNS is the most openly insecure aspect of the entire internet. It’s wide open.
DNS is the most openly insecure aspect of the entire internet. It’s wide open.
So you’re arguing that everybody should switch to DNS over TLS (DoT), then? Sounds great!
DNS over TLS is just DoH but with an easily blocked separate port
Which is great from a local sysadmin perspective. With DoH I have no control of what various apps on devices on my devices are querying.
Or in other words, DoH works better on hostile networks because it looks like just one more HTTPS connection.
That's an intentional design feature. You're attempting to intercept traffic, and any mechanism you could use to do so "transparently" could be used by any hostile network to do so.
You can still intercept traffic from cooperating devices if you want, just not transparently. That's a feature, not a bug, and the Internet will be better for it.
That's an intentional design feature. You're attempting to intercept traffic, and any mechanism you could use to do so "transparently" could be used by any hostile network to do so.
You can still intercept traffic from cooperating devices if you want, just not transparently. That's a feature, not a bug, and the Internet will be better for it.
Right, but I do think this is better handled at the OS layer. Hardcoding everyone to route through Cloudflare is a hardly a net win, and might be better or worse than your ISP depending on who and where you are.
https://support.mozilla.org/en-US/kb/canary-domain-use-appli..., also if you can block it this easily so can the government. The difference with a canary domain is that mozilla can disable it if its misused.
1) other applications or malware won't respect canary domain
2) to implement this canary, you have to break DNSSEC on entire .net root domain. Great.
2) to implement this canary, you have to break DNSSEC on entire .net root domain. Great.
I'm not against DOH but there are definitely some downsides. For example, your token does not get reset on network changes. This means your DNS provider can track your DNS requests across networks, including VPNs.
With normal DNS anyone in the request chain can see a stream of DNS requests but there is no context. By the time the request is one or two hops from you it will be interwoven with tens of thousands of other requests making it impossible to know which one came from who.
With DOH the DNS provider will have a unique identifier to correlate requests back to a specific system/user. Google offers one of the most used DNS services, with DOH they will be able to track all DNS requests you make even if you turn on a VPN.
With normal DNS anyone in the request chain can see a stream of DNS requests but there is no context. By the time the request is one or two hops from you it will be interwoven with tens of thousands of other requests making it impossible to know which one came from who.
With DOH the DNS provider will have a unique identifier to correlate requests back to a specific system/user. Google offers one of the most used DNS services, with DOH they will be able to track all DNS requests you make even if you turn on a VPN.
> Why are people so down on DNS over HTTPS?
It added yet another thing I have to implement, test and maintain through whatever changes they decide to make.
Nothing like adding extra work for every enterprise IT team to make new friends.
There are also some massive security issues with making all https traffic blind that making only the data blind didn't create - like the ability to blackhole known unsafe domains as they appear.
It added yet another thing I have to implement, test and maintain through whatever changes they decide to make.
Nothing like adding extra work for every enterprise IT team to make new friends.
There are also some massive security issues with making all https traffic blind that making only the data blind didn't create - like the ability to blackhole known unsafe domains as they appear.
> DNS is the primary way governments control and spy on web access.
And DoH will enable every device you own to continue spying on you for the benefit of corporations.
DNS is the last bastion of preventing devices I can't sufficiently control from spying on me. I use DNS filtering to block their tracking domains. I use my firewall to prevent devices from accessing DNS resolvers I don't control.
DoH takes those options away from me. Ridiculously, in the name of privacy. Ha!
Unfortunately, the battle was lost the moment someone created a DoH implementation. It hardly matters what the browsers do. All the other things I don't want to have DoH will eventually implement it. And they won't respect use-application-dns.net or whatever other frameworks Mozilla comes up with for controlling DoH at the network level.
(Also, does anyone really believe that governments, ISPs, and public DNS resolvers aren't going to disable DoH with use-application-dns.net? I'm sure whomever came up with DoH in the first place had great intentions but the end result is a disaster that will cause more harm than benefit)
And DoH will enable every device you own to continue spying on you for the benefit of corporations.
DNS is the last bastion of preventing devices I can't sufficiently control from spying on me. I use DNS filtering to block their tracking domains. I use my firewall to prevent devices from accessing DNS resolvers I don't control.
DoH takes those options away from me. Ridiculously, in the name of privacy. Ha!
Unfortunately, the battle was lost the moment someone created a DoH implementation. It hardly matters what the browsers do. All the other things I don't want to have DoH will eventually implement it. And they won't respect use-application-dns.net or whatever other frameworks Mozilla comes up with for controlling DoH at the network level.
(Also, does anyone really believe that governments, ISPs, and public DNS resolvers aren't going to disable DoH with use-application-dns.net? I'm sure whomever came up with DoH in the first place had great intentions but the end result is a disaster that will cause more harm than benefit)
So your point is that your attack model was that makers of malwareApp would try to connect to malwareapp.net instead of a random IP?
If you are worried about traffic in the browser you can not enable it, it you are worried about anything else then VPNs were already a thing since some time ago.
If you are worried about traffic in the browser you can not enable it, it you are worried about anything else then VPNs were already a thing since some time ago.
I suppose my model is that every connected device and app, every web site someone visits, is malware. My household is full of things collecting data and passing it on to entities I don't wish to share that data with.
How do I stop that when my ability to control what happens on my own network has been been reduced to Can access the Internet over 443, or not?
How do I stop that when my ability to control what happens on my own network has been been reduced to Can access the Internet over 443, or not?
My question is how does DoH contributes to that in practice/theory. If a malicious/incompetent app/device wants to access random servers with DoH they would need to include a DoH implementation and then DoH offer nothing more than VPNs. In this context I do not understand if you are worried to have wireguard installed on your connected devices.
If you are talking about Firefox itself, then disable it.
I sympathize with wanting more control, but I do not understand how DoH changes things in a household settings.
(I am assuming your is not a corporate point of view, in that case I agree that DoH might cause significant headaches)
If you are talking about Firefox itself, then disable it.
I sympathize with wanting more control, but I do not understand how DoH changes things in a household settings.
(I am assuming your is not a corporate point of view, in that case I agree that DoH might cause significant headaches)
> I do not understand how DoH changes things in a household settings.
Imagine you run a PiHole or use a service like OpenDNS. It doesn't matter what you've chosen to use or block, what matters is that you've made a choice to utilize DNS filtering for certain things.
You soon discover that some apps and devices don't respect your DNS decisions. They make money or derive other value through communications that are blocked by certain DNS-based filters, so they query 8.8.8.8 or some other DNS directly. You figure out how to make them respect your choice, through a combination of restricting DNS egress and DNAT at the router, and all is well again.
Mozilla and Chrome come along with DoH. That's alright. You can configure them not to. There's the canary domain, so you don't even need to configure browsers manually, tho I expect the canary will eventually go away -- it is destined to be "abused" by every entity in a position to get away with it.
What's going to come next is real the problem: Every entity which can benefit from being able to bypass DNS filters is going to move to DoH. It's in their best interests to do so. They don't need to respect the canary. You won't even be able to tell what they're doing because everything is encrypted with TLS and have pinned their certificates.
App will do it. Embedded devices will do it. Actual malware will do it.
This outcome is inevitable and that is my objection to the mere existence of DoH.
Imagine you run a PiHole or use a service like OpenDNS. It doesn't matter what you've chosen to use or block, what matters is that you've made a choice to utilize DNS filtering for certain things.
You soon discover that some apps and devices don't respect your DNS decisions. They make money or derive other value through communications that are blocked by certain DNS-based filters, so they query 8.8.8.8 or some other DNS directly. You figure out how to make them respect your choice, through a combination of restricting DNS egress and DNAT at the router, and all is well again.
Mozilla and Chrome come along with DoH. That's alright. You can configure them not to. There's the canary domain, so you don't even need to configure browsers manually, tho I expect the canary will eventually go away -- it is destined to be "abused" by every entity in a position to get away with it.
What's going to come next is real the problem: Every entity which can benefit from being able to bypass DNS filters is going to move to DoH. It's in their best interests to do so. They don't need to respect the canary. You won't even be able to tell what they're doing because everything is encrypted with TLS and have pinned their certificates.
App will do it. Embedded devices will do it. Actual malware will do it.
This outcome is inevitable and that is my objection to the mere existence of DoH.
My question is how is DoH different from contacting 1.1.1.1 over https and asking for DNS information without the DNS protocols.
I understand why people do not want this and want control over their own network, I find that a commendable goal. I do not understand how DoH specifically introduces anything new since you could already get DNS data from HTTPS API
I understand why people do not want this and want control over their own network, I find that a commendable goal. I do not understand how DoH specifically introduces anything new since you could already get DNS data from HTTPS API
The two are not unrelated.
Also, turns out that malware has already jumped on the DoH bandwagon.
https://www.google.com/search?q=doh+dns+malware
Also, turns out that malware has already jumped on the DoH bandwagon.
https://www.google.com/search?q=doh+dns+malware
DNS is something network operators (and not just governments and ISPs) has managed and controlled in their own networks for decades.
It has been part of the network stack, with a clear hierarchy in how it is governed:
- network operator - network default
- operating system - application default
- end-user override - when the defaults doesn't work
When something has not worked, you could reliably assume this was the stack used. And you could rely on it being used consistently across all applications.
Needed to deploy internal applications? Great: Just override the (local, internal) DNS. Need to access servers or machines on internal servers? Use DNS!
Now if you make some random applications and decide to flat out ignore the established stack and just ask the internet about DNS...
You're effectively breaking the network and the conventions which has been established to build them.
Ofcourse people are going to hate you. That's a given.
It has been part of the network stack, with a clear hierarchy in how it is governed:
- network operator - network default
- operating system - application default
- end-user override - when the defaults doesn't work
When something has not worked, you could reliably assume this was the stack used. And you could rely on it being used consistently across all applications.
Needed to deploy internal applications? Great: Just override the (local, internal) DNS. Need to access servers or machines on internal servers? Use DNS!
Now if you make some random applications and decide to flat out ignore the established stack and just ask the internet about DNS...
You're effectively breaking the network and the conventions which has been established to build them.
Ofcourse people are going to hate you. That's a given.
> end-user override - when the defaults doesn't work
To my mind, the lack of privacy of classic DNS does indeed count as the the defaults failing to work. Yes, it would be more ideal to solve this at the OS level, but until OS vendors start providing solutions I don't begrudge applications that care about privacy for taking matters into their own hands.
To my mind, the lack of privacy of classic DNS does indeed count as the the defaults failing to work. Yes, it would be more ideal to solve this at the OS level, but until OS vendors start providing solutions I don't begrudge applications that care about privacy for taking matters into their own hands.
1) Instead of proposing changes to the C resolver or a caching resolver the user might run they modified their application to ignore the operating system configuration which is just kind of crappy. Its probably the easiest and most reliable way to block things you don't like and now it doesn't work in firefox.
2) They are the singular (maybe there's one other now heh) resolver operator whereas with DNS anyone (even you) could (and did) run a recursive resolver.
3) I don't think anyone cares so much about this but http is probably the wrong protocol. The DNS protocol was pretty elegant in its efficiency and simplicity (IMO.) Yeah the compression was slightly complex (it's really not) but I've written clients without anything other than a socket library. HTTP on the other hand can do all kinds of complex things and has plenty of room for weirdness and tracking and unintuitive behavior that just isn't necessary for resolving names.
TL;DR: DoH is an unimaginative hack that has a lot of problems from a technical perspective but the social problems are much worse.
2) They are the singular (maybe there's one other now heh) resolver operator whereas with DNS anyone (even you) could (and did) run a recursive resolver.
3) I don't think anyone cares so much about this but http is probably the wrong protocol. The DNS protocol was pretty elegant in its efficiency and simplicity (IMO.) Yeah the compression was slightly complex (it's really not) but I've written clients without anything other than a socket library. HTTP on the other hand can do all kinds of complex things and has plenty of room for weirdness and tracking and unintuitive behavior that just isn't necessary for resolving names.
TL;DR: DoH is an unimaginative hack that has a lot of problems from a technical perspective but the social problems are much worse.
As for 1, if you're choosing to use a special resolver to do content filtering, you can disable DoH yourself. That's suboptimal but in my opinion it's better than not dealing with the broken DNS of the general public.
As for 2), it's not hard to run a DoH server yourself. In fact, it's much safer because it doesn't allow for amplification attacks like traditional DNS. The same goes for DNS over TLS (over TCP).
I agree with you on your third point though. I'd much rather have seen DNS over TLS being built into Firefox, especially as most DoH providers built into Firefox also provide DoT. DoT is easier to set up as well because you don't need any specific DNS server software (just have an nginx proxy the TCP connection to your existing DNS, it's about 10 lines of config).
I discovered that Android's "private DNS" functionality uses DoT. I feared they'd use DoH but luckily I was proven wrong.
As for 2), it's not hard to run a DoH server yourself. In fact, it's much safer because it doesn't allow for amplification attacks like traditional DNS. The same goes for DNS over TLS (over TCP).
I agree with you on your third point though. I'd much rather have seen DNS over TLS being built into Firefox, especially as most DoH providers built into Firefox also provide DoT. DoT is easier to set up as well because you don't need any specific DNS server software (just have an nginx proxy the TCP connection to your existing DNS, it's about 10 lines of config).
I discovered that Android's "private DNS" functionality uses DoT. I feared they'd use DoH but luckily I was proven wrong.
At least when I use my government-controlled DNS which pretends a website doesn’t exist, I can go somewhere else.
I am not down on doh, I'm down on the possibility of Mozilla sending my DNS queries (ie my entire browsing history) to a company I haven't signed a contract with.
And I say the possibility because I'm not American so that's not enabled here (yet). But I trust my ISP and my government much more than I trust Cloudflare (zero) and I will be very disappointed (even more than I already am) at Mozilla if they enable it in the rest of the world.
And I say the possibility because I'm not American so that's not enabled here (yet). But I trust my ISP and my government much more than I trust Cloudflare (zero) and I will be very disappointed (even more than I already am) at Mozilla if they enable it in the rest of the world.
Having just manually enabled DoH, it is pretty tricky to see that DoH is enabled (e.g. from padlock/shield). In the end I saw the necessary flags from: https://www.bleepingcomputer.com/news/software/mozilla-enabl...
Under about:config, it seems like network.trr.mode with values 2 or 3 are good choices, https://wiki.mozilla.org/Trusted_Recursive_Resolver#network....
UPDATE: network.trr.mode with 3 is not working for me in Australia.
Under about:config, it seems like network.trr.mode with values 2 or 3 are good choices, https://wiki.mozilla.org/Trusted_Recursive_Resolver#network....
UPDATE: network.trr.mode with 3 is not working for me in Australia.
Why isn't this being solved on an operating system level instead?
This question should be upvoted more.
Under unix in general (linux, bsd and, I assume, OSX) you can change your system resolver as you please. DoH is supported by several implementations to a various degree already. You can switch right now, for everything running on your system if you wanted to!
But browsers nowdays basically live under the following assumptions:
- the users are dumb, and "we know what's best for you" (well, to be fair this has been a consistent trend for everything in the industry) - the OS cannot be trusted for anything, the baseline being the lowest common denominator of any old/broken version of android/osx/windows/linux they want to support - the users cannot change the system resolver even if they wanted to because the OS is locked down (android, ios, and windows with group policies)
I think all the above reasons are detrimental, but at the same time they're all sadly true. Because browsers essentially are now not far from operating systems, they abstract themselves above everything, including the resolver.
Under unix in general (linux, bsd and, I assume, OSX) you can change your system resolver as you please. DoH is supported by several implementations to a various degree already. You can switch right now, for everything running on your system if you wanted to!
But browsers nowdays basically live under the following assumptions:
- the users are dumb, and "we know what's best for you" (well, to be fair this has been a consistent trend for everything in the industry) - the OS cannot be trusted for anything, the baseline being the lowest common denominator of any old/broken version of android/osx/windows/linux they want to support - the users cannot change the system resolver even if they wanted to because the OS is locked down (android, ios, and windows with group policies)
I think all the above reasons are detrimental, but at the same time they're all sadly true. Because browsers essentially are now not far from operating systems, they abstract themselves above everything, including the resolver.
Well, in the context of DNS resolvers and general computer security the vast majority users are dumb. Mozilla has does know what’s better for them. You, I, all of the readers of Hacker News - we’re the minority.
And for better or worse, the average user’s OS is hostile to a user’s privacy and security, with a few niche exceptions.
And for better or worse, the average user’s OS is hostile to a user’s privacy and security, with a few niche exceptions.
I expect distros that ship a DoH-enabled resolver to force-disable DoH/DoT in browsers.
If operating systems had taken care of the problem already then Mozilla might not have to. I'm glad Mozilla isn't waiting around for them to protect my privacy.
Isn't this gonna cause a bunch of headaches though? What about people who connect to VPN and rely on the local DNS server to resolve non-public hosts? It'll work in everything but Firefox? Seems confusing.
What is the state of the art for Linux resolvers doing encrypted DNS? It looks like systemd's resolver isn't quite ready yet. I found a couple of other things on a quick Google; stubby and dnss.
Is there some simple thing I can apt install on my Ubuntu system?
Is there some simple thing I can apt install on my Ubuntu system?
That would be the best outcome, but until then Mozilla is making an effort to fill the gap until OSes supports DoH, DoT or DNScrypt out of the box and by default.
It could be.
Since Mozilla makes a browser it was natural they'd try to solve it at the application level and not wait until M$ and other privacy loving OS vendors solve the problem.
Since Mozilla makes a browser it was natural they'd try to solve it at the application level and not wait until M$ and other privacy loving OS vendors solve the problem.
Microsoft has already said they're moving to encrypted DNS. Windows Core team announced this to insiders last year.
> Why isn't this being solved on an operating system level
> instead?
It probably should be, but the undertaking is massive (cross platform) and browsers want a quick turn around. A lot of people would think that VPNs solve such issues, but it just pushes the problem further up the network.
In my opinion Linux would be a good candidate for such an initial implementation - but you wouldn't pick DoH, you would likely offer DNSCrypt or DoT.
> instead?
It probably should be, but the undertaking is massive (cross platform) and browsers want a quick turn around. A lot of people would think that VPNs solve such issues, but it just pushes the problem further up the network.
In my opinion Linux would be a good candidate for such an initial implementation - but you wouldn't pick DoH, you would likely offer DNSCrypt or DoT.
Does the disable code still work in the about:config? I would rather not have the trusted providers see all our internal server names (which is wasted bandwidth and time) and our controls in the library work.
DNS resolution is the OS's job. This hijacking of function is a pain. Has no one at Mozilla ever had to deal with the realities of using their browser in an organization?
DNS resolution is the OS's job. This hijacking of function is a pain. Has no one at Mozilla ever had to deal with the realities of using their browser in an organization?
Network/Organization Operators have various ways to disable DoH in their orgs or networks, for example via a canary domain or enterprise policies. https://support.mozilla.org/en-US/kb/configuring-networks-di...
AFAIK the ESR (business release) does not have this on by default
ESR is extended support and we use the regular Firefox. Firefox was never required by any vendor we use to remain compatible so we didn't have to be on the ESR branch.
https://support.mozilla.org/en-US/kb/canary-domain-use-appli... You can use this if you run a DNS server
I have some unusual, from the normal browser user perspective, DNS stuff and this just leads to a bunch of questions.
My gateway has a bunch of static DNS entries for internal hosts, which are all in a fake top-level domain. How will resolving these work if the request goes to CloudFlare? CloudFlare obviously doesn't know about my internal domain. Currently my gateway resolves what it knows about and uses my ISP's DNS to resolve what it doesn't.
Pi-Hole is presents a similar problem.
Finally, if DoH is the future, how do I run my own DoH server which can resolve internal hosts? Does such software even exist yet? How do I point Firefox at this DoH server? The relevant Wikipedia article[0] points to a list of public DoH servers I can use, but offers no insight as to what software I'd use to run one for my own use.
[0] https://en.wikipedia.org/wiki/DNS_over_HTTPS
My gateway has a bunch of static DNS entries for internal hosts, which are all in a fake top-level domain. How will resolving these work if the request goes to CloudFlare? CloudFlare obviously doesn't know about my internal domain. Currently my gateway resolves what it knows about and uses my ISP's DNS to resolve what it doesn't.
Pi-Hole is presents a similar problem.
Finally, if DoH is the future, how do I run my own DoH server which can resolve internal hosts? Does such software even exist yet? How do I point Firefox at this DoH server? The relevant Wikipedia article[0] points to a list of public DoH servers I can use, but offers no insight as to what software I'd use to run one for my own use.
[0] https://en.wikipedia.org/wiki/DNS_over_HTTPS
cloudflared, knot-resolver, stubby, unbound, CoreDNS can be run as DoH and/or DoT stub and/or recursive resolvers, locally.
The easiest stub resolver to setup would be nextdns' client: https://github.com/nextdns/nextdns
The easiest stub resolver to setup would be nextdns' client: https://github.com/nextdns/nextdns
Your setup will still work. Firefox is configured with a "fallback" situation, where anything that doesn't resolve on the public resolver will be queried again using your system-configured DNS options.
As for Pi-hole, my recommendation is to block NATed traffic to Cloudflare's DoH traffic (forcing it into Fallback mode) and then setting up Pi-Hole to use for it's recursive resolution.
Alternatively, you can setup your own DoH server based off BIND: https://terminaladdict.com/networking/linux/2019/09/13/DoH.h...
As for Pi-hole, my recommendation is to block NATed traffic to Cloudflare's DoH traffic (forcing it into Fallback mode) and then setting up Pi-Hole to use for it's recursive resolution.
Alternatively, you can setup your own DoH server based off BIND: https://terminaladdict.com/networking/linux/2019/09/13/DoH.h...
I’m gonna get some heat for this, but that’s OK; it’s my honest opinion.
I can’t really think of a better way to hamper progress on an open specification then by delegating the problem to some private corporation; especially one that has a penchant for censorship.
If more than .0003% of people actually used Firefox, we would have to worry about Cloudflare taking over the entire Internet. So it’s probably a good thing Mozilla ruined their brand over the past decade.
I would be willing to bet money that Mozilla is getting paid millions of dollars by Cloudflare for this.
In the meantime, this is the final straw for me. I’m done with Firefox for life. I haven’t used anything but Firefox since 2007... 13 years...
I can’t really think of a better way to hamper progress on an open specification then by delegating the problem to some private corporation; especially one that has a penchant for censorship.
If more than .0003% of people actually used Firefox, we would have to worry about Cloudflare taking over the entire Internet. So it’s probably a good thing Mozilla ruined their brand over the past decade.
I would be willing to bet money that Mozilla is getting paid millions of dollars by Cloudflare for this.
In the meantime, this is the final straw for me. I’m done with Firefox for life. I haven’t used anything but Firefox since 2007... 13 years...
How does this work with hosts that are not resolvable outside your own network? If I tell firefox to go to internalsite.mycompany.com - which resolves internally, but not outside our network - how is firefox going to resolve it, if it's not using our DNS servers?
Correct.
In order to preserve compatibility, Firefox's implementation has a "fallback" where if it sees that it can't resolve a domain, then it will fail back to using the system-configured DNS provider.
In order to preserve compatibility, Firefox's implementation has a "fallback" where if it sees that it can't resolve a domain, then it will fail back to using the system-configured DNS provider.
You can also exclude specific domains but at this point they have to be written in about:config.
https://support.mozilla.org/en-US/kb/firefox-dns-over-https#...
It looks like Firefox Policies can be used to enable, disable, or specify the DoH provider but cannot yet specify excluded domains.
https://github.com/mozilla/policy-templates
https://support.mozilla.org/en-US/kb/firefox-dns-over-https#...
It looks like Firefox Policies can be used to enable, disable, or specify the DoH provider but cannot yet specify excluded domains.
https://github.com/mozilla/policy-templates
I wonder why they don't simply check if the user's resolv.conf is configured to resolve via a private IP address, and not use DoH if that's the case.
So now just one company will have access to all the data from 99% of firefox users? I don't see how giving so much power to just one entity is better for our privacy.
Previously if I used my computer at home, coffee shop, work, hotel etc it would be very hard if not impossible for one company to get all of my browsing history. And giving it all to one company is a better idea?
Previously if I used my computer at home, coffee shop, work, hotel etc it would be very hard if not impossible for one company to get all of my browsing history. And giving it all to one company is a better idea?
And many routers also cache local DNS requests. So unless someone can see every router that you were served by at every airport, hotel, coffeeshop, they really can't see where you've been browsing by examining DNS requests.
We're _much_ less safe having cloudflare know all.
We're _much_ less safe having cloudflare know all.
Seems very marginal for privacy when people in the middle can still see the IP you're connecting to, just not which DNS record you may have retrieved the IP with.
Run wireshark on an ssl connection. The server certificate is sent in plaintext. It includes the DNS name of the server you connected to.
DoH would make sense in a world where that was fixed. (Though DNS over TLS is also a thing, and makes strictly more sense than DoH from what I can tell...)
DoH would make sense in a world where that was fixed. (Though DNS over TLS is also a thing, and makes strictly more sense than DoH from what I can tell...)
It's actually quite massive. Most sites (well not most, but a lot) sit behind something like cloudflare, so your scummy intercepting ISP would only see a connection to cloudflare. Of course none of this really means too much until encrypted SNI is a thing but it's a definitely a lot more than marginal imo
You can sort of assume anybody paying any attention to traffic is sniffing the SNI information, it's pretty obvious.
Encrypted SNI is a parallel and related effort to that, though.
So hopefully not a cause that's lost forever, but we can improve more in the future.
So hopefully not a cause that's lost forever, but we can improve more in the future.
Not all ISPs around the world have the resources to do that. It also doesn't have to be 100%, we just have to make it difficult (or more expensive) and that helps.
Good point. Sniffing traffic is orders of magnitude more expensive than simply logging DNS queries.
tcpdump -i any -s 1500 '(tcp[((tcp[12:1] & 0xf0) >> 2)+5:1] = 0x01) and (tcp[((tcp[12:1] & 0xf0) >> 2):1] = 0x16)' -nnXSs0 -ttt
0x0110: c008 0016 0013 0010 000d c00d c003 000a ................
0x0120: 00ff 0100 0113 0000 001d 001b 0000 186c ...............l
0x0130: 6f67 7369 6e6b 2e64 6576 6963 6573 2e6e ogsink.devices.n
0x0140: 6573 742e 636f 6d00 0b00 0403 0001 0200 est.com.........It's not complicated, but that's also going to take more time , cpu power, and memory bandwidth to do so than just recording dns packets. When you need to do that to millions or billions of connections per second the costs start to really add up.
It’s just bitmask and slicing basically, that would work just fine even on hosts with obscene amounts of traffic.
It gets more difficult when you deal with aggregated traffic in the 10s or 100s of Gbps.
But yes, it is possible.
One thing is though - TLS1.3 is getting more popular and so is session resumption. So even now quite a bit of traffic cannot be identified and it will get harder and harder.
Encrypting DNS requests is one required piece of the puzzle.
But yes, it is possible.
One thing is though - TLS1.3 is getting more popular and so is session resumption. So even now quite a bit of traffic cannot be identified and it will get harder and harder.
Encrypting DNS requests is one required piece of the puzzle.
Sure, that would work for a SOHO gateway, but at ISP scale that's a ton more traffic to be sniffing.
[deleted](1)
It's far easier for ISPs to scrape up your DNS queries (they run the resolver) than it is for the to make correlations based on IP addresses, especially with multiple websites hosted on the same IP.
So all DoH does (once ESNI is eventually a thing) is alter this equation. ISPs will simply begin correlating IPs (and CT logs: http://blog.seanmcelroy.com/2019/01/05/ocsp-web-activity-is-...) instead.
Until recently, I was working at CZ.NIC and people who are working on Knot DNS resolver were in the next office. The easiest way to get them crazy was to mention DNS over HTTPS. They hated it passionately.
Many DNS folks hate it; https://twitter.com/paulvixie/status/1053765281917661184
I wish they wouldn't do this. I trust my ISP more than I trust Firefox and whatever company they chose for DNS over HTTP.
This "We know better than you" attitude is why I stopped using Firefox so many years ago. I switched back recently, to stop using Chromium, but I have a growing list of annoyances, and it might be time to give NeXt Browser a chance again, or see what else is out there.
This "We know better than you" attitude is why I stopped using Firefox so many years ago. I switched back recently, to stop using Chromium, but I have a growing list of annoyances, and it might be time to give NeXt Browser a chance again, or see what else is out there.
"Firefox defaults to Cloudflare, though you can change this."
So it's whichever company you choose for DNS, rather than the company chosen by your ISP. Many of us were already choosing not to use the ISP's DNS, for reliability, but with this feature the ISP can't eavesdrop on that.
So it's whichever company you choose for DNS, rather than the company chosen by your ISP. Many of us were already choosing not to use the ISP's DNS, for reliability, but with this feature the ISP can't eavesdrop on that.
Most of us chose a company already, our ISP (or in my case a mixture of first + third party). Firefox are defaulting to their choice, no?
Presumably they give an option page on which to choose it - even they wouldn't be so egregious as to hide such a massive change without positive user consent, surely?
Presumably they give an option page on which to choose it - even they wouldn't be so egregious as to hide such a massive change without positive user consent, surely?
Well, honestly, I don't use my ISP's DNS, either, but that just highlights another way this is annoying: Firefox is overriding my decision with their own.
And like I said, I trust my ISP more than I trust Firefox and CloudFlare, so their spying on my DNS (if they even are) is less of a concern to me than CloudFlare or Firefox spying on the requests.
And like I said, I trust my ISP more than I trust Firefox and CloudFlare, so their spying on my DNS (if they even are) is less of a concern to me than CloudFlare or Firefox spying on the requests.
While I may or may not trust cloudflare more than my isp, the fact is that my isp has my billing information and address on file. I do not pay anything or provide any personal information to cloudflare. So to me, there is an advantage to not having all my eggs in one basket. While I'm sure cloudflare could tie your DNS lookups to your identity, it would be much less trivial for them than your isp.
Agreed, I dislike the paternalism and wish competition in the browser space was much more robust. I'm Google averse and hooked on Tree Style Tabs so Firefox it is for the time being
The most important thing this prevents are DNS based MITM attacks where they intercept your request and send you an IP address they control.
DNSSEC anyone? Or DNSCurve, or DNSCrypt.
DNSSEC does nothing to provide DNS privacy, nor does it address MITM attacks between endpoints (your phone and laptop) and DNS servers; it's a server-to-server protocol. DNSSEC is moribund; practically no important sites run it.
DNSCurve/DNSCrypt are directly competitive with DoH, but in a post-DoH world, both are probably dead-letter standards.
DNSCurve/DNSCrypt are directly competitive with DoH, but in a post-DoH world, both are probably dead-letter standards.
For people in Switzerland I recommend using the DNS/DoH services provided by the Digitale Gesellschaft [2]. There is no logging and no block list. [1]
[1] https://www.digitale-gesellschaft.ch/2019/04/11/oeffentliche...
[2] https://www.digitale-gesellschaft.ch/dns/
[1] https://www.digitale-gesellschaft.ch/2019/04/11/oeffentliche...
[2] https://www.digitale-gesellschaft.ch/dns/
I predict that DoH will break many enterprise infrastructures that rely on custom DNS servers. Unwary sysadmins that update Firefox will be in a lot of trouble when they switch this on by default.
We ourselves have a custom DNS setup with an only internally resolvable TLD as a security measure, so this change will break our infra for all Firefox users (thankfully we’re in the EU so we’re spared, for now).
Good thing that Cloudflare wants to centralize DNS and access control anyway, so those enterprises can just switch to their proprietary DNS service and VPN replacement, I guess ;)
We ourselves have a custom DNS setup with an only internally resolvable TLD as a security measure, so this change will break our infra for all Firefox users (thankfully we’re in the EU so we’re spared, for now).
Good thing that Cloudflare wants to centralize DNS and access control anyway, so those enterprises can just switch to their proprietary DNS service and VPN replacement, I guess ;)
Firefox by default is configured with a fallback option, where if resolution would fail, it will fallback to the system-provided DNS servers. So your internal TLDs are safe.
Additionally, if you've setup Firefox to be installed with Firefox for Enterprise, DoH is disabled by default and you've got nothing to worry about. DOH is able to be configured through GPO as well, allowing the use of a custom server.
Additionally, if you've setup Firefox to be installed with Firefox for Enterprise, DoH is disabled by default and you've got nothing to worry about. DOH is able to be configured through GPO as well, allowing the use of a custom server.
And that is even more dangerous, it would mean that if for some reason an identical domain extists on the internet (or somebody registers it to do an attack) then all the hosts will connect to the malicious external domain and not the correct host in the internal network. Local hosts should be resolved FIRST.
Also cloudfare this way gets the DNS names of your internal hosts, you are leaking information that otherwise would be private, and system administrator will probably not think about that!
Also with that option is not really secure at all, if somebody wants to intercept your DNS requests he can simply block the IPs of Cloudfare DNS over HTTPS server and then read the DNS requests unencrypted.
Also cloudfare this way gets the DNS names of your internal hosts, you are leaking information that otherwise would be private, and system administrator will probably not think about that!
Also with that option is not really secure at all, if somebody wants to intercept your DNS requests he can simply block the IPs of Cloudfare DNS over HTTPS server and then read the DNS requests unencrypted.
You should only use a domain you own or something that isn't routable. You can't blame FF for that
That was an issue with .dev and then google acquired the TLD.
In all reality, your Enterprise should own the domain externally. What happens if one day a configuration flag is flipped and you're no longer resolving internally the domain?
If you have a problem with Cloudflare, go setup your own, it's just BIND9 with some SSL certs.
If you have a problem with Cloudflare, go setup your own, it's just BIND9 with some SSL certs.
There is already support for enterprise situations like you describe: https://support.mozilla.org/en-US/kb/canary-domain-use-appli...
Well, ok, but this requires updating all company DNS servers so it’s still far from ideal I would say. They should have done it the other way around: if the DNS returns a specific response enable DoH, otherwise leave it alone.
I recently upgraded my home router to DNS over HTTP (pfSense now supports it pretty easily).
I started with Quad9 (9.9.9.9) and Cloudflare as a backup (1.1.1.1).
One thing I noticed right away was that my ping times to Cloudflare ended up being way faster (15ms) compared to Quad9 (50ms). Cloudflare seems to have a presence in my local area.
Now both are good, but adding a 50ms delay (+TCP handshake + TLS setup and teardown) seemed like a non-trivial amount. I ended up putting Cloudflare first.
There was a noticeable difference, something to think about if you decide to set this up.
I started with Quad9 (9.9.9.9) and Cloudflare as a backup (1.1.1.1).
One thing I noticed right away was that my ping times to Cloudflare ended up being way faster (15ms) compared to Quad9 (50ms). Cloudflare seems to have a presence in my local area.
Now both are good, but adding a 50ms delay (+TCP handshake + TLS setup and teardown) seemed like a non-trivial amount. I ended up putting Cloudflare first.
There was a noticeable difference, something to think about if you decide to set this up.
> Cloudflare seems to have a presence in my local area.
In case you're interested in rolling out your own low-latency DoH: I run a DoH stub-resolver on Cloudflare Workers [0]. Their free-tier covers one device's worth traffic. You could do so on stackpath, too [1].
[0] https://news.ycombinator.com/item?id=22208988
[1] https://news.ycombinator.com/item?id=19514791
In case you're interested in rolling out your own low-latency DoH: I run a DoH stub-resolver on Cloudflare Workers [0]. Their free-tier covers one device's worth traffic. You could do so on stackpath, too [1].
[0] https://news.ycombinator.com/item?id=22208988
[1] https://news.ycombinator.com/item?id=19514791
Can someone please explain why there can’t be a DHCP or RA option for which DoH server to use? Why are we going out of our way to make sure the sysadmin has to configure each and every piece of software on each and every single PC rather than just set it one in a centralized location, like every other networking option?
DoH will leave my machines unable to resolve all my internal domain names, right?
DoH will leave my machines unable to resolve all my internal domain names, right?
I'm not sure how firefox could implement this entirely on their end. There would need to be cooperation on the OS (or dhcp client) side to expose that option somehow.
We're in this mess because OSes haven't acted and Mozilla has had to take matters into their own hands. Unfortunately any solution that requires cooperation from other software is going to take a lot longer to land.
I do hope it happens eventually, and I'm sure that when it does Mozilla will change Firefox again to respect that.
We're in this mess because OSes haven't acted and Mozilla has had to take matters into their own hands. Unfortunately any solution that requires cooperation from other software is going to take a lot longer to land.
I do hope it happens eventually, and I'm sure that when it does Mozilla will change Firefox again to respect that.
It can get even more complicated when you have multiple connections on your machine, each with a different DNS server. You'd need to match the DNS server determination algorithm of the operating system to remain consistent, which is one hell of a task.
There's also the fact that there's no DHCP option reserved for DoH/DoT/DNScrypt (yet) which requires some standardisation work.
There's various APIs to read the current DHCP configuration for a network interface so technically it shouldn't be too hard (at least not when it comes to Windows or macOS where there's standard APIs, as opposed to Linux whose modular layout makes finding a standard location for DHCP config difficult).
There's also the fact that there's no DHCP option reserved for DoH/DoT/DNScrypt (yet) which requires some standardisation work.
There's various APIs to read the current DHCP configuration for a network interface so technically it shouldn't be too hard (at least not when it comes to Windows or macOS where there's standard APIs, as opposed to Linux whose modular layout makes finding a standard location for DHCP config difficult).
If you have multiple connections, each of those DNS servers should return the same answers.
If they do not, they should be marked as forwarders for their respective domains. Something like `Add-DnsClientNrptRule -Namespace "domain.com" -NameServers "1.2.3.4"`
The operating system will have this information; an application, like browser, won't.
If they do not, they should be marked as forwarders for their respective domains. Something like `Add-DnsClientNrptRule -Namespace "domain.com" -NameServers "1.2.3.4"`
The operating system will have this information; an application, like browser, won't.
I don't think so. Someone like Mozilla can "claim" a DHCP option code and say "this is what we are going to use, operating systems can climb aboard if they want."
Firefox is still falling back to local DNS settings if it can't resolve stuff using the currently set DoH provider, as I can access resources in Firefox on my university's network that cannot be resolved outside it.
Does it submit every FQDN via DoH? So does Cloudflare see myspookybox.zeveb? Because if so then even that is an information leak.
It's very frustrating to be constantly downvoted for saying that Firefox's DoH implementation leaks information without any of the downvoters saying why.
Seriously, do you disagree that it leaks information? Do you agree that it does, but believe it is less problematic for two companies to have this information than having it sharded across all ISPs? Do you agree that it's more problematic but you don't care for some other reason? Do you agree that it's problematic and care but don't like how I express my point? Do you agree, care and like my expression but think it adds no value to HN?
I can't learn if we don't discuss the issue.
Seriously, do you disagree that it leaks information? Do you agree that it does, but believe it is less problematic for two companies to have this information than having it sharded across all ISPs? Do you agree that it's more problematic but you don't care for some other reason? Do you agree that it's problematic and care but don't like how I express my point? Do you agree, care and like my expression but think it adds no value to HN?
I can't learn if we don't discuss the issue.
Perhaps you could check with Wireshark for DoH traffic (ie https to Cloudflare) when resolving a local domain?
(I agree with what you've said here, FYI)
(I agree with what you've said here, FYI)
In prefer the approach Google is taking with Chrome and Microsoft is taking with Windows 10 which is to use the system defined DNS servers and if they support DoH to use it and if not to fallback to using them with normal DNS.
There is no need to configure individual applications and no need to develop a new means of distributing DoH server information.
There is no need to configure individual applications and no need to develop a new means of distributing DoH server information.
https://support.mozilla.org/en-US/kb/canary-domain-use-appli...
There is. You configure your DNS resolve this "canary" domain to disable it.
There is. You configure your DNS resolve this "canary" domain to disable it.
You missunderstood.
He wants to tell his devices that they should use a specific DoH reaolver, instead of their default.
All that does is block DoH entirely, right? Not allow me to say “use this DoH server” or “don’t use DoH for this domain.”
Here are the instructions to do it, straight from Mozilla: https://support.mozilla.org/en-US/kb/firefox-dns-over-https#...
On Windows, you can probably do this via GPOs. How does one configure a fleet of Mac or Linux machines? How does one do it with BYOD or on a campus of students' machines?
Perhaps some thought as to service discovery should have been done:
* https://tools.ietf.org/html/rfc6763
If Mozilla is going to re-invent the wheel (OSes already do DNS look ups), they perhaps should have asked the DNS folks (e.g., DNS-OARC) about some of the corner/use cases IMHO.
Perhaps some thought as to service discovery should have been done:
* https://tools.ietf.org/html/rfc6763
If Mozilla is going to re-invent the wheel (OSes already do DNS look ups), they perhaps should have asked the DNS folks (e.g., DNS-OARC) about some of the corner/use cases IMHO.
I think if you want to get that detailed you'd be pushing a custom managed Firefox profile.
You have twenty different applications using DoH for “increased security” and you need a custom profile for each? Why not a single line in resolv_doh.conf?
What local resolver supports resolv_doh.conf at this time?
At the moment, Mozilla wants to push this for users where DoH just works, for people it doesn't providing options to disable it.
Once resolv_doh.conf becomes a thing for all platforms (Linux, OSX and Windows) they can use that.
At the moment, Mozilla wants to push this for users where DoH just works, for people it doesn't providing options to disable it.
Once resolv_doh.conf becomes a thing for all platforms (Linux, OSX and Windows) they can use that.
Is it a big deal to have your internal domain names accessible externally? Many (though not all) DNS server allow private IPs in DNS.
It creates a vulnerability for external devices -- they're trying to communicate with myhost.mydomain.com but really they're talking to whatever device has the same IP address on the network they're attached to.
Some DNS hosters disallow private IPs. Some public resolvers and consumer routers will filter out responses containing private IPs.
Some DNS hosters disallow private IPs. Some public resolvers and consumer routers will filter out responses containing private IPs.
It means making my internal name sever accept recursive calls from the internet at large. You’re proposing degrading my network security for this.
This can cause DNS rebind attacks.
A great step indeed for websites that use static IP for a single resource. Websites that uses Server Name Indication TLS extension for shared hosting force clients to send the hostname in plain-text during TLS handshake which could be sniffed. (Reliance Jio in India is already doing it https://cis-india.org/internet-governance/blog/reliance-jio-...).
The Same thing OCSP Stapling (Online Certificate Status Protocol) extension which also sends the hostname.
Cloudflare crafted a solution for this by storing the public key of the target website along with the DNS record. So during DoH when the user asks for IP of a given host, it can also get the public key of the host. User then establishes the TCP, encrypt the SNI extension & OCSP with the public key and starts the TLS handshake.
Though ESNI doesn't seem to provide perfect forward secrecy it is a leap forward.
The Same thing OCSP Stapling (Online Certificate Status Protocol) extension which also sends the hostname.
Cloudflare crafted a solution for this by storing the public key of the target website along with the DNS record. So during DoH when the user asks for IP of a given host, it can also get the public key of the host. User then establishes the TCP, encrypt the SNI extension & OCSP with the public key and starts the TLS handshake.
Though ESNI doesn't seem to provide perfect forward secrecy it is a leap forward.
If you're about to comment on how dumb this is because SNI isn't encrypted please halt and search "ESNI"
Draft only. OpenSSL doesn't support it - because it's still a draft. So as of now, ESNI does not provide anything.
It is moving forward, albeit slowly. With or without DoH/DoT, non encrypted SNI is a problem, and DoH/DoT have privacy improvements in their own right.
"moving forward" doesn't help anyone. Standards and more importantly, implementations count.
In every DoH/DoT discussion there is someone who mentions ESNI, but without major level support this is a vague promise. Of course DNS encryption is still useful even without ESNI.
In every DoH/DoT discussion there is someone who mentions ESNI, but without major level support this is a vague promise. Of course DNS encryption is still useful even without ESNI.
What difference does it make? Even if the DNS queries are completely encrypted, subsequent HTTPS requests made after domain resolution will contain the destination domain (but not the path or request body) in the clear. What makes you assume that ISPs aren't already collecting this information?
The Host header is encrypted when using HTTPS and the SNI is encrypted when using ESNI. In the best scenario (DoH + HTTPS + ESNI), ISPs only get the destination IP, not the destination domain.
That's not so great for a best case scenario, because destination IPs rarely change, and anyone can resolve any domain themselves, making it easy to associate a timestamped IP with a DNS record. I could walk the whole HSTS preload list to find domains.
The how many IP does pornhub.com have?
Quite a few, I guess, but you'd probably be more concerned about how many other domains share the same IP addresses rather than about how many IP addresses this domain resolves to. And the answer seems to be thousands of domains — which in this case doesn't help much as they seem to all be related, but which in other cases might (eg. shared hosting, CDNs…).
We just published our proposal of a decentralized DoH resolution to address this exact problem of single-point-of-trust/failure. As Firefox is looking for more reliable partners for their "Trusted Recursive Resolver program", we strongly believe and hope that "K-resolver" will be seriously considered as an option to improve DNS privacy for not only Firefox users, but also the general Internet.
https://twitter.com/NP_tokumei/status/1220802795512578048?s=...
https://arxiv.org/pdf/2001.08901
https://twitter.com/NP_tokumei/status/1220802795512578048?s=...
https://arxiv.org/pdf/2001.08901
The overhead of setting up and using an https connection is massive compared to DNS which can fit in a UDP transaction.
Do they establish a connection and leave it open for a long period? Supporting that would be a big commitment on the part of the resolvers.
Do they establish a connection and leave it open for a long period? Supporting that would be a big commitment on the part of the resolvers.
Small DNS queries and answers fit in one UDP packet, but larger ones don't and have to be retried as TCP.
HTTPS/2 over TLS 1.3 (which is the baseline you should assume for these relatively new services) is one TCP setup plus potentially 0-RTT TLS on all but the first visit.
0-RTT is safe here because a DNS query is just a question with no side effects. Replay attacks (the risk 0-RTT incurs) don't do anything:
Gumby: "What is the IPv4 address of news.ycombinator.com?" encrypted so that only DoH Server and you can read it
Server: "209.216.230.240" encrypted so that only Gumby and the DoH server can read it
Attacker: Replays Gumby's packet with no knowledge what it means
Server: Same reply, also unintelligible to attacker just like the original
For HTTPS/3 (over QUIC rather than TLS+TCP) it's UDP so the only "overhead" is from the crypto setup which is modest on even a relatively weak machine.
HTTPS/2 over TLS 1.3 (which is the baseline you should assume for these relatively new services) is one TCP setup plus potentially 0-RTT TLS on all but the first visit.
0-RTT is safe here because a DNS query is just a question with no side effects. Replay attacks (the risk 0-RTT incurs) don't do anything:
Gumby: "What is the IPv4 address of news.ycombinator.com?" encrypted so that only DoH Server and you can read it
Server: "209.216.230.240" encrypted so that only Gumby and the DoH server can read it
Attacker: Replays Gumby's packet with no knowledge what it means
Server: Same reply, also unintelligible to attacker just like the original
For HTTPS/3 (over QUIC rather than TLS+TCP) it's UDP so the only "overhead" is from the crypto setup which is modest on even a relatively weak machine.
Thanks. I hadn't followed the development of 0-RTT which allows the server to tear down the connection.
There aren't that many DNS names out there. Eventually we should be able to just replicate the entire DNS database (or large parts of it) to routers or even local devices. Then your lookups don't go outside of your network.
Well, it can be quite a lot of data for many network devices and then you may have outdated replication.
The current system using a cache works relatively well until you want privacy.
The current system using a cache works relatively well until you want privacy.
I may be late to this, but here [1] is some commentary on why DoH (DNS over HTTPS) may not be as affective as it is perceived. The article also talks about DoT (DNS over TLS) mechanism which is apparently less disruptive for network monitoring tools compared to DoH.
Can some security minded folks from the community chime in about the claims made in the linked article?
(Disclaimer: English is my second language)
[1]: https://www.zdnet.com/article/dns-over-https-causes-more-pro...
Can some security minded folks from the community chime in about the claims made in the linked article?
(Disclaimer: English is my second language)
[1]: https://www.zdnet.com/article/dns-over-https-causes-more-pro...
The article has several good points but also some weak ones.
For example, it points out that DoH doesn't really protect privacy from ISPs because ISPs can still see what the users are doing because the ISPs route the traffic. Then, it claims that DoH weakens security because it would let users get around malware blacklists. However, this is mostly nonsense for the same reason. Malware (and other legitimate blacklisting) can and should be blocked even when hard-coded IP addresses are used.
The point about the logistics is very true, though. I won't use DoH at home because I operate my own DNS that contains intranet addresses not accessible from the outside Internet. DoH in Firefox would break those services.
For example, it points out that DoH doesn't really protect privacy from ISPs because ISPs can still see what the users are doing because the ISPs route the traffic. Then, it claims that DoH weakens security because it would let users get around malware blacklists. However, this is mostly nonsense for the same reason. Malware (and other legitimate blacklisting) can and should be blocked even when hard-coded IP addresses are used.
The point about the logistics is very true, though. I won't use DoH at home because I operate my own DNS that contains intranet addresses not accessible from the outside Internet. DoH in Firefox would break those services.
When end-user privacy is your goal, disrupting network monitoring tools is a feature, not a bug.
I'm really looking forward to enable the feature on my personal computer. But as long as Firefox DoH ignores my /etc/hosts configuration, I won't use it.
I hope it's just a matter of time before they fix this :)
I hope it's just a matter of time before they fix this :)
Yes please, I'm using /etc/hosts all the time when I setup new servers and to access some servers with no name on customer VPNs.
I'm getting pretty pissed off the with the arrogance of US internet tech companies sidestepping formal protocol design & industry adoption because it isn't moving "fast enough" for them. Without ESNI, DoH is essentially meaningless for the class of privacy invaders it is supposed to combat against. By the time ESNI is out, DoT would have had enough time to mature and gain wide enough adoption.
DoT is better because at least it's obvious if your ISP/Gov is blocking port 853 (at which point you install a VPN or run your own resolver somewhere and tunnel to it or swap provider or move country). Meanwhile you get all the usual benefits of decentralised DNS resolution and don't have to worry about the unforeseen overhead and bullshit DoH is going to spwan.
Firefox is an app for browsing websites. What business does it have pushing a half baked compromise solution that undermines core infrastructure, creates a false sense of privacy and introduces second order effects that will result in DNS lookups being centralised in to the hands of a few giant US corporations (at least changing to 1.1.1.1 or 8.8.8.8 was opt-in).
Also can't wait for the inevitable instances of Cloudflare deciding not to resolve certain domains (effectively becoming the de-facto arbitrator of what most FF users can and cannot see on-line). For a preview of that, try going to archive.is with 1.1.1.1 as your resolver.
Ultimately, all of this is moot anyway (even once ESNI arrives). Regardless of DNS, your device still needs to connect to an IP. Entities interested in where you are going will still be able to get reasonable insight by simply correlating IP addresses and CT logs (http://blog.seanmcelroy.com/2019/01/05/ocsp-web-activity-is-...). The only decent solution to this, and available right now, is a VPN (at which point DNS privacy is automatically solved for you).
If Paul Vixie thinks DoH is a bad idea then... it's a bad fucking idea: https://twitter.com/paulvixie/status/1053765281917661184
DoT is better because at least it's obvious if your ISP/Gov is blocking port 853 (at which point you install a VPN or run your own resolver somewhere and tunnel to it or swap provider or move country). Meanwhile you get all the usual benefits of decentralised DNS resolution and don't have to worry about the unforeseen overhead and bullshit DoH is going to spwan.
Firefox is an app for browsing websites. What business does it have pushing a half baked compromise solution that undermines core infrastructure, creates a false sense of privacy and introduces second order effects that will result in DNS lookups being centralised in to the hands of a few giant US corporations (at least changing to 1.1.1.1 or 8.8.8.8 was opt-in).
Also can't wait for the inevitable instances of Cloudflare deciding not to resolve certain domains (effectively becoming the de-facto arbitrator of what most FF users can and cannot see on-line). For a preview of that, try going to archive.is with 1.1.1.1 as your resolver.
Ultimately, all of this is moot anyway (even once ESNI arrives). Regardless of DNS, your device still needs to connect to an IP. Entities interested in where you are going will still be able to get reasonable insight by simply correlating IP addresses and CT logs (http://blog.seanmcelroy.com/2019/01/05/ocsp-web-activity-is-...). The only decent solution to this, and available right now, is a VPN (at which point DNS privacy is automatically solved for you).
If Paul Vixie thinks DoH is a bad idea then... it's a bad fucking idea: https://twitter.com/paulvixie/status/1053765281917661184
> Regardless of DNS, your device still needs to connect to an IP.
All of the bad actors from the users’ perspective (ads, tracking, etc.) will sit behind Cloudflare, Cloudfront, etc. and you won’t be able to do anything about it.
All of the bad actors from the users’ perspective (ads, tracking, etc.) will sit behind Cloudflare, Cloudfront, etc. and you won’t be able to do anything about it.
Seems to be a trend lately. Google recently announced they will start blocking downloads from http websites. Doesn't sound like a bad idea -- but isn't this more a discussion for IETF as well?
The discussion should be around improved UX/UI and better protocols rather than treating people like idiots and abusing your power to unilaterally force behaviour changes on web content providers and consumers.
The more I think about it the more I realise Microsoft's and AOL's instincts were right. Make the internet a walled garden and insert yourself as the gatekeeper.
Their mistake was to do this too early. ~25 years later and the people are now finally ready and willing to allow billion dollar coporates to overtly "manage" their on-line experience for them. Companies love this too because it removes yet one more unseemly shackle from their ambition (i.e. that of needing to work collaboratively with potential competitors) while at the same time providing them with a nice vector to defend their quasi monopoly.
The more I think about it the more I realise Microsoft's and AOL's instincts were right. Make the internet a walled garden and insert yourself as the gatekeeper.
Their mistake was to do this too early. ~25 years later and the people are now finally ready and willing to allow billion dollar coporates to overtly "manage" their on-line experience for them. Companies love this too because it removes yet one more unseemly shackle from their ambition (i.e. that of needing to work collaboratively with potential competitors) while at the same time providing them with a nice vector to defend their quasi monopoly.
Cloud flare is American and we know since the PRISM scandal that US based tech companies are directly plugged into the NSA, and everybody in the chain will deny it under the threat of prison.
So, if this rolls out 'as-is' in any other country than the US, we will go from "all DNS requests are clear text, but dispatched among many entities" to "DNS requests are encrypted, but all read and controlled by american agencies".
We (may) have gain (some) privacy (maybe). But we also (certainly) gained a serious dependency.
So, if this rolls out 'as-is' in any other country than the US, we will go from "all DNS requests are clear text, but dispatched among many entities" to "DNS requests are encrypted, but all read and controlled by american agencies".
We (may) have gain (some) privacy (maybe). But we also (certainly) gained a serious dependency.
NSA don’t factor into my personal threat model _at all_ where random ISPs snooping and selling do. I would gladly give the NSA all of my traffic unencrypted in exchange for decent commercial privacy
I supposed not having a dictatorship regime in your country history book helps to see things that way.
Given the way my country went from freedom to "regime de Vichy" in a few years, during my grandpa time, I don't want a state level entity having that kind of power.
Since the US state level entities decided they could now ignore Habeas Corpus and legitimated torture, secret courts and declared impunity for them-self, I especially don't want them to have that kind of power.
Given the way my country went from freedom to "regime de Vichy" in a few years, during my grandpa time, I don't want a state level entity having that kind of power.
Since the US state level entities decided they could now ignore Habeas Corpus and legitimated torture, secret courts and declared impunity for them-self, I especially don't want them to have that kind of power.
If a malicious power takes over your country they’ll hit you with a rubber hose until you give up your secrets much before they give a shit about your internet history, I suspect.
Quite the contrary, as shown by as most dictatorships across the world trying to control their piece of the internet. The biggest example being the Big Firewall of China.
This let them control how people think, communicate, consume and inform them-self. But also detects anyone that could oppose the regime. Or make a graph of all allies, suspects, etc.
Then you hit them with a rubber hose :)
This let them control how people think, communicate, consume and inform them-self. But also detects anyone that could oppose the regime. Or make a graph of all allies, suspects, etc.
Then you hit them with a rubber hose :)
That is the case if they are targeting you, what you should likely worry about is if they take interest in you.
They only enabled it by default for US users, so at this time it doesn't really matter. shrugs
When they roll out in the EU, I will pay close attention to how they are doing it, what partners they use under what jurisdictions etc.
When they roll out in the EU, I will pay close attention to how they are doing it, what partners they use under what jurisdictions etc.
Same.
Gotta also make sure I don't get a US Firefox build somehow.
Gotta also make sure I don't get a US Firefox build somehow.
You can always disable DNS-over-HTTPS in the network preferences, or set or own resolver, e.g. https://news.ycombinator.com/item?id=22412656
But good point, now I am curious how they detect US-ness. Probably a combination of using the en-US and some geo lookup?
But good point, now I am curious how they detect US-ness. Probably a combination of using the en-US and some geo lookup?
The page, which you didn't read, specifically makes the point that they have no plans to roll this out (by default) anywhere except for the US.
Nowhere it says they have no plan of doing it. They just release it only for the US __build__, __by default__, __now__.
But to make things more honest, I'll edit my comment.
But to make things more honest, I'll edit my comment.
One point I haven't seen covered yet is split-horizon DNS where there are actually servers listening on both sides of the horizon (though possibly different ones).
Example #1: I have a personal server running at home that is reachable from the internet through a PageKite tunnel. It's reachable through a public address of the form https://xyz.pagekite.me. The connection is secured by a Let's Encrypt certificate, which means I have to use this address to avoid HTTPS errors and the domain has to be reachable from the internet so I can fulfill challenges.
However, I'd also like to access the server from my LAN without an unnecessary round-trip through the internet: I might want to avoid unnecessary data costs or display certain content only available to LAN clients. So from the internet, the domain should resolve to the PageKite tunnel, but inside the LAN, the domain should resolve directly to the server's LAN address.
This is relatively easy to accomplish using traditional DNS: Just set up a local DNS server that serves the LAN address. However, how do you do that with DoH?
Example #2: You want to set up an internet router at home. The instructions ask you to connect to www.routerlogin.net to pull up the web interface. The domain is split-horizon: When requested through the router, it will resolve to the router's internal address and be served by the router's internal web server. When requested from the internet, it will point to a generic info page from the vendor.
Now with DoH, you'd always see the generic info page, even when connecting through the router.
Example #1: I have a personal server running at home that is reachable from the internet through a PageKite tunnel. It's reachable through a public address of the form https://xyz.pagekite.me. The connection is secured by a Let's Encrypt certificate, which means I have to use this address to avoid HTTPS errors and the domain has to be reachable from the internet so I can fulfill challenges.
However, I'd also like to access the server from my LAN without an unnecessary round-trip through the internet: I might want to avoid unnecessary data costs or display certain content only available to LAN clients. So from the internet, the domain should resolve to the PageKite tunnel, but inside the LAN, the domain should resolve directly to the server's LAN address.
This is relatively easy to accomplish using traditional DNS: Just set up a local DNS server that serves the LAN address. However, how do you do that with DoH?
Example #2: You want to set up an internet router at home. The instructions ask you to connect to www.routerlogin.net to pull up the web interface. The domain is split-horizon: When requested through the router, it will resolve to the router's internal address and be served by the router's internal web server. When requested from the internet, it will point to a generic info page from the vendor.
Now with DoH, you'd always see the generic info page, even when connecting through the router.
This is kind of a sub-issue but from the infographic in TFA:
>Q. Will DoH lead to a greater centralization of DNS, which will be bad for the Internet as a whole?
>A. We agree that centralization is bad for the Internet. Today in practice, DNS is >centralized because consumer devices are locked to the DNS service of the ISPs. >And just five companies control over 80% of the US broadband internet market.
For one thing, 5 independent providers within the same country is not exactly centralized in my opinion. As far as I understand it Americans don't always effectively have the choice of which ISP they can use, but that's not a technological problem. You won't solve monopolistic and anti-competitive practices with a new layer 7 protocol.
Furthermore what does Mozilla mean by "locked to the DNS service of the ISPs", do they block DNS queries to other services? Here in Europe I can switch to a different DNS any time I want. Sure, it's easier to stick with the defaults and most people will do that but "locked" is a strong word which I suspect is inaccurate in this case.
By that definition of "centralized" you could argue that email is effectively centralized since most people just use the free service provided by a handful of providers.
>The immediate impact of Mozilla enabling DoH in Firefox will be less >centralization, not more because it shifts traffic away from large ISPs, and >provides users with more choice, while respecting enterprise DNS >configurations.
So 5 ISPs meant that the service was effectively centralized, but (at this time) two competing DoH services with Cloudflare selected by default is "less centralization"?
>Q. Will DoH lead to a greater centralization of DNS, which will be bad for the Internet as a whole?
>A. We agree that centralization is bad for the Internet. Today in practice, DNS is >centralized because consumer devices are locked to the DNS service of the ISPs. >And just five companies control over 80% of the US broadband internet market.
For one thing, 5 independent providers within the same country is not exactly centralized in my opinion. As far as I understand it Americans don't always effectively have the choice of which ISP they can use, but that's not a technological problem. You won't solve monopolistic and anti-competitive practices with a new layer 7 protocol.
Furthermore what does Mozilla mean by "locked to the DNS service of the ISPs", do they block DNS queries to other services? Here in Europe I can switch to a different DNS any time I want. Sure, it's easier to stick with the defaults and most people will do that but "locked" is a strong word which I suspect is inaccurate in this case.
By that definition of "centralized" you could argue that email is effectively centralized since most people just use the free service provided by a handful of providers.
>The immediate impact of Mozilla enabling DoH in Firefox will be less >centralization, not more because it shifts traffic away from large ISPs, and >provides users with more choice, while respecting enterprise DNS >configurations.
So 5 ISPs meant that the service was effectively centralized, but (at this time) two competing DoH services with Cloudflare selected by default is "less centralization"?
> do they block DNS queries to other services?
Some providers use MitM attacks on DNS queries, to do things like block content or replace NXDOMAIN with SPAM. (Probably obviously, this is not possible with DoH.)
Some providers use MitM attacks on DNS queries, to do things like block content or replace NXDOMAIN with SPAM. (Probably obviously, this is not possible with DoH.)
Will /etc/hosts still work? I was surprised it is ignored completely after DNS over HTTPS is enabled. I don't see why it can't first consult this standard local source regardless of DoH. This is making development more painful. Similarly to how Android stopped supporting locally-installed custom CA certificates globally for all apps, making HTTPS debugging impossible. :(
I guess most of the people against this change have been lucky enough to never live in a place where the internet is actively censored.
It must be nice living in a place where you don't have to worry about access. But for many of us, there's no point in privacy without access.
It must be nice living in a place where you don't have to worry about access. But for many of us, there's no point in privacy without access.
Why not make it opt in then?
Opera added the same option today too https://blogs.opera.com/desktop/2020/02/r2020-opera67-tidy-y...
https://bugzilla.mozilla.org/show_bug.cgi?id=1614751
Firefox won't bother checking the canary domain if the user clicked "OK" to the DNS-over-HTTPS question.
Firefox won't bother checking the canary domain if the user clicked "OK" to the DNS-over-HTTPS question.
ITT: Some very annoyed sysadmins that didn’t read the enterprise deployment guide and who apparently rely on “pretty please don’t exfiltrate data” as their enforcement mechanism.
Are they surprised that a change made in the name of preventing your local network operator from slurping your DNS information doesn’t create a way for local network operators to just ignore DoH and slurp DNS information?
Are they surprised that a change made in the name of preventing your local network operator from slurping your DNS information doesn’t create a way for local network operators to just ignore DoH and slurp DNS information?
If you want to control this via Group Policy, or system-wide, you can use the following policy:
https://github.com/mozilla/policy-templates#dnsoverhttps
https://github.com/mozilla/policy-templates#dnsoverhttps
I want it to do something when stuff doesn't work. Replacing one thing with another might improve the situation (or not) but the real problem is failure imho.
To needlessly ramble on a bit: A simple header or html tag could "ok" all or specific alternative ways of distributing and provide conditions. Say, if my blog is unavailable for > 3 months you can p2p distribute it by [for example] fast, medium or supper slow means. Currently I look at articles I wrote long ago. I've carefully selected 10-30 links of which 20% still work(!?) I've picked them specifically because they are probably unfamiliar to those interested in the topic.
To needlessly ramble on a bit: A simple header or html tag could "ok" all or specific alternative ways of distributing and provide conditions. Say, if my blog is unavailable for > 3 months you can p2p distribute it by [for example] fast, medium or supper slow means. Currently I look at articles I wrote long ago. I've carefully selected 10-30 links of which 20% still work(!?) I've picked them specifically because they are probably unfamiliar to those interested in the topic.
So basically instead of hundreds of different DNS systems, all an unsupervised person in government or law enforcement has to do is search one or two distinct DNS services for all your queries over the past years.
They can claim all they want it's not logged or anonymized but that's like believing the same claims by your VPN service, you have no idea if they are operating under a silent security order from some agency.
And unless I am missing something, unless you are tunneling though VPN, proxy, etc. your ISP is well aware of every IP connection you do, they simply just rDNS if they want to know.
They can claim all they want it's not logged or anonymized but that's like believing the same claims by your VPN service, you have no idea if they are operating under a silent security order from some agency.
And unless I am missing something, unless you are tunneling though VPN, proxy, etc. your ISP is well aware of every IP connection you do, they simply just rDNS if they want to know.
I don’t know why DNS over HTTPS breaks my brain.
I understand how DNS, HTTP, and most of HTTPS work at the wire level (a little fuzzy on how the decisions are made, though). It’s just using a different transport strategy to acquire an IP address from a FQDN. Every step of that process has a logic to it, and none are mutually incompatible.
And yet... my brain keeps alerting, asking what kind of madman does the HTTP before the DNS. Maybe it’s the “to make an HTTP connection, first you must make an HTTP connection” part that gets me. I can’t say. But it just feels wrong, despite being more sustainable.
I understand how DNS, HTTP, and most of HTTPS work at the wire level (a little fuzzy on how the decisions are made, though). It’s just using a different transport strategy to acquire an IP address from a FQDN. Every step of that process has a logic to it, and none are mutually incompatible.
And yet... my brain keeps alerting, asking what kind of madman does the HTTP before the DNS. Maybe it’s the “to make an HTTP connection, first you must make an HTTP connection” part that gets me. I can’t say. But it just feels wrong, despite being more sustainable.
Anecdata: I frequent a local café that only offers Facebook Wi-Fi, which requires you to "check in" on Facebook in order to receive Internet access.
I don't have a Facebook account but with Firefox TRR, 'google.com' is the only address that resolves just fine — so I search Google (or directly from the address bar) for a website, click through to the result, and the ensuing session is allowed. Rinse and repeat for each new tab.
Any direct attempt to browse otherwise (including to google.com with other browsers) always hits the FB captive portal.
I don't have a Facebook account but with Firefox TRR, 'google.com' is the only address that resolves just fine — so I search Google (or directly from the address bar) for a website, click through to the result, and the ensuing session is allowed. Rinse and repeat for each new tab.
Any direct attempt to browse otherwise (including to google.com with other browsers) always hits the FB captive portal.
Does anyone know when something like this might come to Brave?
I know Brave is supposed to be a privacy-centric browser, but their plan for advertising seems at odds with that. Advertising is a slippery slope and I wonder how long before these promises are eroded or outright reversed.
> 100% of your ad spend is placed for active users that opt-in to a rewarding private ad experience.
> Craft effective offers and provide captivating full-page experiences directly with consumers in Brave’s Private Ad Tabs.
> Brave uses local machine learning with the browser profile to only place ads in optimal conditions. Ads are matched to opportunities, and users become partners instead of targets.
> Private ad matching efficiently matches ads directly from the device, without breaching personal information.
https://brave.com/brave-ads-waitlist/
> 100% of your ad spend is placed for active users that opt-in to a rewarding private ad experience.
> Craft effective offers and provide captivating full-page experiences directly with consumers in Brave’s Private Ad Tabs.
> Brave uses local machine learning with the browser profile to only place ads in optimal conditions. Ads are matched to opportunities, and users become partners instead of targets.
> Private ad matching efficiently matches ads directly from the device, without breaching personal information.
https://brave.com/brave-ads-waitlist/
I think the only reason Brave wasn't immediately laughed out of the room on HN as a browser that literally shows you its own ads is because they brilliantly have their own cryptocoin (BAT) so that anyone who thinks their $10 investment will buy them a lambo one day will come out of the woodwork to mention the browser.
The same thing you saw happen to any other cryptocurrency. It basically kills all earnest conversation.
The Brave thought this was worthwhile makes the whole thing feel scummy to me. But we are way off topic.
The same thing you saw happen to any other cryptocurrency. It basically kills all earnest conversation.
The Brave thought this was worthwhile makes the whole thing feel scummy to me. But we are way off topic.
BAT is necessary in order to allow decentralized payments from users to site operators with no intermediary. No centralized alternative system would be sufficient for Brave's use-case.
Advertising doesn't have to be at odds with privacy. So long as the user agent is in charge of deciding what ads to show rather than a centralized server (which is the entire point of Brave), no user data needs to be revealed to anyone.
> I know Brave is supposed to be a privacy-centric browser, but their plan for advertising seems at odds with that.
I know "Have I Been Pwned" is supposed to be a security tool for white hats, but the fact that they collected hundreds of millions of users passwords seems at odds with that.
Additionally, there's a service called 1password that leverages this data. It claims to be a tool to help users know if their password has been compromised. But a service that has the ability to check a user's current password against a database seems at odds with that.
On a completely unrelated note-- do you know how Brave actually implements advertising in their browser?
I know "Have I Been Pwned" is supposed to be a security tool for white hats, but the fact that they collected hundreds of millions of users passwords seems at odds with that.
Additionally, there's a service called 1password that leverages this data. It claims to be a tool to help users know if their password has been compromised. But a service that has the ability to check a user's current password against a database seems at odds with that.
On a completely unrelated note-- do you know how Brave actually implements advertising in their browser?
1Password is a very popular password manager.
If I recall correctly, brave://flags should have "Secure DNS" or something like that.
Sweet! Did not know about that. Ask a question, learn something new. Now I have knobs to play with. :)
Bottom of the infographic appears to contain a new Firefox logo. Looking at their website, it appears this is actually the logo for the larger (and somewhat confusingly named) Firefox suite of products, to distinguish them from the Firefox browser. Which is nice I guess, but what most people see is the browser icon, and this logo would be far preferable to the current one in that capacity.
Can someone at Mozilla explain why they present what is purely textual content as a PNG?
I mean, this is ridiculous: https://ffp4g1ylyit3jdyti1hqcvtb-wpengine.netdna-ssl.com/net...
I mean, this is ridiculous: https://ffp4g1ylyit3jdyti1hqcvtb-wpengine.netdna-ssl.com/net...
The fun part is that this seems to have been copied from an HTML FAQ and a link "see relevant documentation here" has simply disappeared in the process.
It’s to keep with the theme of breaking the web while ostensibly replacing it with something better.
It even seems to break inline links, like in the "split-horizon" section:
> System administrators can find relevant documentation here.
I'm pretty sure "here" should be a link, but of course that doesn't work when the marketing department uses a PNG instead of HTML.
I'm also surprised that Mozilla / the CDN don't optimize the PNG. `zopflipng` reduces the size from 285K to 153K.
And of course it's named "Final-DNS-over-HTTPS-05-1.png".
> System administrators can find relevant documentation here.
I'm pretty sure "here" should be a link, but of course that doesn't work when the marketing department uses a PNG instead of HTML.
I'm also surprised that Mozilla / the CDN don't optimize the PNG. `zopflipng` reduces the size from 285K to 153K.
And of course it's named "Final-DNS-over-HTTPS-05-1.png".
I clicked.
They could've used an image map. /s
They could've used an image map. /s
For sharing on social media / chat apps.
Apparently, screen reader users do not deserve to be able to learn about the future of the web Mozilla is envisioning.
When you click on it then the text gets smaller. Bizarre choice.
I noticed that too. Totally inaccessible. Very un-Mozilla like.
For sharing on Twitter?
Oh well, I just hope this enforcing new third parties to my internet browsing doesn't catch on.
Guess I will disable it.
Guess I will disable it.
how long does Cloudflare or NextDNS retain dns query logs?
Only the NSA will know. Isn't it them who send those secret letters to US companies?
24h except for "sampling".
I still don't trust them. Clouldflare is simply way too big and has done a lot of shady controversial stuff. I also feel like this is breaking something fundamental about the operating system. DNS queries are now going to be different between your browser and ... the rest of your operating system.
How does Firefox deal with corporate installations and internal DNS?
How does Firefox deal with corporate installations and internal DNS?
> How does Firefox deal with corporate installations and internal DNS?
Everything is configurable and there are canaries to override that.
Everything is configurable and there are canaries to override that.
> Everything is configurable
But how many people are going to change it from the default?
But how many people are going to change it from the default?
A corporate environment or internal DNS is already changing the defaults.
It is disabled by default in Firefox ESR and enterprise environments are already using GPO to manage it anyway.
Firefox will detect when it has enterprise administrative policies set and disable DoH. The parental control topic though is still very much open. Mozilla's statement is that they are "working with the industry to define appropriate standards that will enable smooth functioning of opt-in parental controls" provided by ISP. No word on when or if only these ISP controls will be considered.
Also, why limit the choices to just those two? If you're going to provide an app-based service for this, why not allow the user to use any DoH server they want to use? Did Mozilla make some kind of deal with Cloudflare and NextDNS?
The Firefox settings UI allows the user to set a custom DoH server. For example, Quad9 is yet another DNS provider that hosts DoH servers:
https://www.quad9.net/doh-quad9-dns-servers/
https://www.quad9.net/doh-quad9-dns-servers/
They have contracts with Cloudflare and NextDNS to limit what information can be collected, retention policies, and explicitly saying that it can't be sold.
You can use your own resolver.
More information about data retention requirements for DOH-resolver partners:
https://wiki.mozilla.org/Security/DOH-resolver-policy
https://wiki.mozilla.org/Security/DOH-resolver-policy
This thing should never be on by default. Mozilla here has decided for me that it is an acceptable layering violation on my system/network. IMHO, this thing is bordering on malware.
Does anyone know when Brave Browser might get something like this? I like the thing that on issues like this, folks at Brave and Mozilla are in similar pages (pun?).
I’m wondering, is the US a phased roll out or is this in light of government mandated censorship in the UK, Australia, New Zealand, India, China, etc.?
The last entry at their FAQ posted today indicates that they’re focusing on US-only and does not commit to worldwide plans. (But it’s also buried in an image where I can’t copy-paste, ugh.) Link to that FAQ:
https://blog.mozilla.org/netpolicy/2020/02/25/the-facts-mozi...
https://blog.mozilla.org/netpolicy/2020/02/25/the-facts-mozi...
I think OP's question is why it is US only.
The only reason I can think of (or I can understand) is regulation and laws, but it doesn't seem to be the case.
The only reason I can think of (or I can understand) is regulation and laws, but it doesn't seem to be the case.
Is there a way to ensure the ISP opt-in parent control is not going to be abused, effectively turning it into a way to bypass DoH at all?
No, well, maybe, depending on your country. I know some countries have laws preventing ISPs from interfering with content, but even those laws do not apply to technical measures, like DoH, they are still completely free to block it.
I run my own DNS server. So I trust my own DNS way more than I trust Cloudflare. Is there a way to stop Firefox from using DNS over HTTP?
Yes, it supports custom resolvers, see the section "Switching Providers": https://support.mozilla.org/en-US/kb/firefox-dns-over-https
How will courts blocking domains work after this?
Much more effectively: A single party to issue an order to instead of a great number.
So all WiFi logins which abuse & hack DNS weaknesses like airports & hotels don't work with Firefox anymore?
I think DoH itself is a good thing. What seems fishy though is hardcoding Cloudflare as the default DoH service.
It's absolutely not hardcoded.
Not technically, but you know what I mean.
In this forum, only you know what you mean until you write words. When you write a word like "hardcoded", which means a specific thing, is it not reasonable to expect people to think that you meant "not really hardcoded".
As one of my favorite people told me once: words mean things. The words we use matter, as humans do not have telepathy.
As one of my favorite people told me once: words mean things. The words we use matter, as humans do not have telepathy.
Yeah, you're right.
Great. I already enabled it explicitly.
[deleted]
What's to stop ISPs from simply setting the canary and turning off DoH?
I wonder what the implications of DoH will be for TCP-over-DNS ...
How likely is it that the other browsers will eventually do this?
Very likely. IIRC, it's working its way into Chromium, and once it's there it will be everywhere.
https://www.chromium.org/developers/dns-over-https
https://www.chromium.org/developers/dns-over-https
[deleted]
If I2P was widely used, we wouldn't need this.
So FireFox will now not simply query my internal DNS server? Good luck with that, because I've disabled outbound DNS except from that server.
Guess I'm not using FireFox any more. :(
Guess I'm not using FireFox any more. :(
Due to the Cloud Act, this is probably the end of Mozilla as a browser used in a business setting for non-US companies.
A naïve protocol capsuled inside a stupid and dangerous protocol.
A naïve protocol capsuled inside a stupid and dangerous protocol.
is this only on desktop ? i cant find this setting on android
Can you disable this?
Yes, instructions to do so are in the article.
In preferences search for DNS. You'll find a checkbox to enable/disable it along with a select for choosing a provider.
What are some reasons why someone would prefer to or need to disable it. Just curious.
I'm not sure if disabling it is the right way to go, but I do not plan on letting Firefox ship all my DNS queries to CloudFlare. I do not trust Cloudflare any more (and maybe a little less honestly) than my ISP.
I do want a container with my own DNS-over-HTTP running on my own hosted VM (or Digital Ocean, or Vultr or Linode or whoever) and I'll ship my DNS queries there.
I do want a container with my own DNS-over-HTTP running on my own hosted VM (or Digital Ocean, or Vultr or Linode or whoever) and I'll ship my DNS queries there.
There is an interesting guide (in French) on best-practices to get DoH up and running with dnsdist (https://dnsdist.org) here: https://www.bortzmeyer.org/doh-mon-resolveur.html.
You might also be interested in looking at https://dnsdist.org/guides/dns-over-https.html
You might also be interested in looking at https://dnsdist.org/guides/dns-over-https.html
Some folks have a dnscrypt server for their LAN already, and/or use Split-Horizon DNS on their networks. Systems are already configured to use those setups at the system level, and having to have per-app dns settings now is madness.
I'm in the "this should be done by the system resolver" camp, and I hope they figure out how to push that for all the major platforms ...
I'm in the "this should be done by the system resolver" camp, and I hope they figure out how to push that for all the major platforms ...
It's essentially the same question as "why would you choose another DNS server?"
There are numerous other options like Google, Quad9, OpenDNS, OpenNIC, DNSWatch or Verisign, each of which have pros and cons like speed, privacy, reliability or accuracy. Many people also use VPNs which provide DNS servers that are perceived to increase privacy.
I know this is currently US only but were it to roll out worldwide, personally I'm in a country with strong legal privacy protections and trust my ISP far more than any American company.
There are numerous other options like Google, Quad9, OpenDNS, OpenNIC, DNSWatch or Verisign, each of which have pros and cons like speed, privacy, reliability or accuracy. Many people also use VPNs which provide DNS servers that are perceived to increase privacy.
I know this is currently US only but were it to roll out worldwide, personally I'm in a country with strong legal privacy protections and trust my ISP far more than any American company.
A lot of networks run their own DNS. You can give resolvable hostnames to hosts internal to the LAN. You can cache queries on an organization-wide boundary and only go to the internet with those queries when the TTL expires.
In my home setup I'm already using DNS over TLS to talk to the internet, but on the LAN requests go to my DNS server, get cached there, etc.
In my home setup I'm already using DNS over TLS to talk to the internet, but on the LAN requests go to my DNS server, get cached there, etc.
My computer, my User agent, my rules. I want to be in 100% control over DNS queries (logging/blocking).
Why do you want to not disable it I would say. Having DNS over HTTPS not only completely breaks local name resolution (e.g. http://fileserver) and you must manually specify IP addresses in the browser to connect to local hosts, but also if you already have (like I have on my LAN) a local DNS server that does DNS over TLS is useless and also you don't benefit from for example query filtration (I filter out ad servers and trackers from DNS requests)
To use their etc/hosts entries, to use pihole, to run their own DNS server, etc
I have Pi-hole on my network and I do not want to use any other DNS provider other than my own (with my own blacklist/whitelist).
[deleted]
Yes. The article linked to explains how.
In an effort to further protect the privacy of its users online, Firefox has begun rolling out encrypted DNS over HTTPS (DoH) by default for US-based users.
To be honest I don't use Firefox that much compared to Chrome.
To be honest I don't use Firefox that much compared to Chrome.
Glad I don’t use it.
I just uninstalled firefox and switched to chromium for good (or bad).
Anybody have any stats on what percentage of websites and or percentage of global web-traffic hits websites that are hosted on their own personal unshared IP, vs those that are hosted on shared IPs?
Because if 90% of websites are hosted on unshared IPs, then this whole thing about DoH and/or ESNI providing some sort of privacy is complete bunk. An ISP can still see exactly what website you're visiting when connecting to an unshared IP by virtue of which IP you're connecting to. The methods for mapping a raw IP to a website when that IP is unshared, are numerous and effective.
DoH/ESNI only provide privacy if the vast majority of websites are on shared IPs.
DoH/ESNI only provides privacy if we have already (or are planning to) centralise web traffic behind a handful of gatekeepers.
Because if 90% of websites are hosted on unshared IPs, then this whole thing about DoH and/or ESNI providing some sort of privacy is complete bunk. An ISP can still see exactly what website you're visiting when connecting to an unshared IP by virtue of which IP you're connecting to. The methods for mapping a raw IP to a website when that IP is unshared, are numerous and effective.
DoH/ESNI only provide privacy if the vast majority of websites are on shared IPs.
DoH/ESNI only provides privacy if we have already (or are planning to) centralise web traffic behind a handful of gatekeepers.
Multiple downvotes because I pointed out that the whole promise of DoH is that it stops ISP's from being able to see and sell which websites you're visiting, but ISP's will still be able to see and sell which websites you're visiting, unless we stick most websites behind shared IPs.
I guess that's step 2 in "advancing" the web.
I guess that's step 2 in "advancing" the web.