SoylentNews is people
SoylentNews
How to Enable DNS-Over-HTTPS (DoH) in Firefox:
The DNS-over-HTTPS [(Doh)] protocol works by taking a domain name that a user has typed in their browser and sending a query to a DNS server to learn the numerical IP address of the web server that hosts that specific site.
This is how normal DNS works, too. However, DoH takes the DNS query and sends it to a DoH-compatible DNS server (resolver) via an encrypted HTTPS connection on port 443, rather than plaintext on port 53.
This way, DoH hides DNS queries inside regular HTTPS traffic, so third-party observers won't be able to sniff traffic and tell what DNS queries users have run and infer what websites they are about to access.
Further, a secondary feature of DNS-over-HTTPS is that the protocol works at the app level. Apps can come with internally hardcoded lists of DoH-compatible DNS resolvers where they can send DoH queries.
This mode of operation bypasses the default DNS settings that exist at the OS level, which, in most cases are the ones set by local internet service providers (ISPs).
This also means that apps that support DoH can effectively bypass local ISPs traffic filters and access content that may be blocked by a local telco or local government -- and a reason why DoH is currently hailed as a boon for users' privacy and security.
[...] The below step-by-step guide will show Firefox users in the UK and Firefox users all over the world how to enable the feature right now, and not wait until Mozilla enables it later down the road -- if it will ever do. There are two methods of enabling DoH support in Firefox.
The fine article then presents step-by-step instructions on two methods to enable DoH in Firefox, as well as an explanation of what the various setting values mean.
(Score: 4, Insightful) by The Mighty Buzzard on Monday July 08 2019, @11:09AM (18 children)
As a user I have to say this is a good thing. It gives control and privacy to the users. As an admin I hate it. For exactly the same reasons.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Monday July 08 2019, @11:54AM (4 children)
It's a nightmare for admins who need to do content blocking (schools etc). If web apps ever get to specify "DoH" servers under the pretence of "security", it'll become a nightmare for users too. Also; The inefficiency of additional HTTP + encryption overhead makes me want to puke.
(Score: 3, Interesting) by c0lo on Monday July 08 2019, @12:36PM (3 children)
<tongue_in_cheek>Look, the inefficiency of a hierarchical DNS and multiple roundtrips to different servers with recursive queries makes me want to puke. Like, why can't I make a single query and get the answer straight away?</tongue_in_cheek>
Point: everything in relation with Internet is a trade-off. The only point of debate is where you set the point of balance, and that depends on what you can afford to still consider good-enough one way or the other. Mid '90-ies, the users will curse you if you had a site with over 1MB of eye-candy images - righto, dial-up speeds.
Nowadays, you have tens-to-hundred of megs of javascript to download, going over HTTPS-everywhere, before even the first bits of useful info start hitting your browser, Guess what? the majority of users accept the trade-off, not even being aware it's actually their interest is the most compromised (a lot of data processing and page layouting happen into the client browser instead of on the serverside, so the server-side is cheaper 'cause it doesn't do any dynamic "rendering" - JSON content only. And the front-end devs are happy too - dynamic rendering means more flexible display layout, cheaper maintenance, shorter dev times - a design that's more "responsive" to whatever the markedroids throw at the engineering team and the zillions of device aspect ratios/resolution that content need to be displayed on).
Where does this lets your puke? A self-evident answer, don't you think?
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 0) by Anonymous Coward on Monday July 08 2019, @12:56PM (2 children)
That's not inefficient, transferring entire registries for every update would be inefficient.
A couple of meg, once with correct cache headers. Few JS heavy sites provide any functional benefit over vanilla html - that's a different argument and one I expect we'd agree upon.
Aside from all the negatives (overhead, hard coded DNS in apps & hijacking) there is also a potential positive. The time for alternate DNS roots has arrived.
(Score: 3, Touché) by c0lo on Monday July 08 2019, @01:19PM
Enjoy your FB-captive DNS root, I hope you like it.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 0) by Anonymous Coward on Monday July 08 2019, @07:03PM
Alternate roots? You must be joking. I can't get my mother to understand the difference between single clicks and double clicks, nor can I get her to understand that left clicks and right clicks do different things. The only way she could install an alternate root is if one of those stupid "cursor packs" or "themes" she tries to install all the time had one in it next to the RCE and privileged escalation attack for the Linux distro installed.
(Score: 4, Interesting) by zocalo on Monday July 08 2019, @12:36PM (4 children)
HTTPS already gives you *some* privacy in that you can only capture the domain part of the URL, not the actual page within the site, which is encrypted (yes, there are ways around this). An ISP intercepting DNS and HTTPS requests, or routing web traffic via a transparent proxy, would already get the IP address of a host (possibly a shared IP on a CDN or cloud host) and the domain being visited. DoH means the ISP can't as easily intercept the DNS request, but they can still capture the metadata of the connection that gets established, which still includes the destination IP:port and the domain name if it's routed via a proxy). They can go even further if they do deep packet inspection, but of course that's not cheap at scale and they understandably don't want to pay for something many feel is too easily circumvented just to put a tick into a government provided box and keep the Daily Mail and the rest of the "Think of the children/But terrorists!" crowd off their backs.
The biggest objection to DoH, viz. ISPA nominating Mozilla as Internet Villain, seems to be circumvention of blocklists. What it seems like they actually mean is circumvention of their cheap and easy implementation of blocklisting that anyone with a little nous or an idea what to Google can figure out how to get around pretty easily so now they'll need to spend more money to continue to tick that government provided box. Changing DNS servers to unfiltered ones isn't hard (and works for most UK ISPs), implementing your own DNS is slightly harder but still pretty easy for anyone who can follow a HOWTO (or just buy a pre-built Pi-Hole) for the rest, and if all else fails then you can always switch to another ISP and/or use a VPN. But yeah, more money, so it's "Mozilla: you suck!"
UNIX? They're not even circumcised! Savages!
(Score: 4, Interesting) by Immerman on Monday July 08 2019, @01:40PM (3 children)
I was thinking the same thing - establishing a secure connection to the "phone book" does offer some substantial protection against domain redirection and some other issues, but it wouldn't seem to do anything to stop the "phone company" from knowing who you "call" - they still have to know that, because they're still the ones actually directing your "call". At least for the first hop - onion routing, or even a single encrypted hop to a proxy beyond their control would solve that, but that's a completely different project.
As for government required block lists, I see two obvious solutions. The first is technical: block the current IP address rather than just the DNS table entry. You do have to keep the addresses up to date, but that's a minor detail. My guess is that any government serious about blocklists
The second is legal - declare accessing secure DNS servers that don't cooperate to be a crime. Or worse, declare using secure DNS lookups themselves to be a crime. They're the government, they don't have to worry about technical solutions.
(Score: 3, Interesting) by jmorris on Monday July 08 2019, @02:45PM (2 children)
Your idea is a good decade out of date. These days half of the Internet resolves to a cloudflare IP. Large masses of customers resolve to any one IP and it randomizes regularly to make keep up with it difficult. That is part of the design, to make IP blocking impractical.
This new wrinkle makes DNS blocking harder. Easiest solution is to simply ban it. Build a block list of every DoH server and ban them by IP at the firewall. That gets the well known IPs people will hard code into browsers, then have your resolver point all of their names to a page explaining why they are not allowed on the network. This is a stupid privacy invading idea and when Moz does stupid things the answer is to award a stupid prize.
Yes it is an attempt to solve an actual problem, the ISPs were greedy and stupid. But every attempt at solving a problem should be examined to see if it creates a new obvious problem. DoH failes that test.
(Score: 2) by zocalo on Monday July 08 2019, @04:10PM
Cloudflare is also somewhat notorious for refusing to "take down" sites because, quite correctly, they can often claim not to host the site itself, so twinned with a bulletproof provider for the actual hosting of the site (whose IPs are masked by Cloudflare) and takedowns become very hard indeed. Yeah, there's a very good reason why so much of the grey-to-black side of the Internet is on Cloudflare IPs... I'm pretty sure most competent ISPs running IP-based blocklists realise all this, but as long as they can be seen to be going through the motions of implementing the list and the authorities don't seem inclined to close the loop hole and raise the ridiculously low bar to circumvent the blocks, everyone's happy.
UNIX? They're not even circumcised! Savages!
(Score: 2) by Immerman on Wednesday July 10 2019, @01:41AM
I don't care about IP blocking though - I care about privacy against surveillance. And every IP packet specifies the specific source and destination IP address it's traveling between, and those can't be faked because the TCP protocol requires active acknowledgement from the receiver that each packet made it successfully in order to sustain the data transfer.
So, does Cloudfare shuffle IP addresses enough that knowing the specific IP address User A is currently communicating with, Surveillance Officer B won't be able to identify the website if they try to connect to the same IP address at the same time? It seems unlikely, but I don't know their implementation details.
(Score: 2) by RS3 on Monday July 08 2019, @01:46PM (5 children)
If you're an admin, say for a school, library, etc., you'll employ a filtering engine that will trap the DoH traffic and either block it, provide the DNS yourself but log it, redirect it, whatever.
Or maybe I'm missing something?
(Score: 0) by Anonymous Coward on Monday July 08 2019, @02:02PM
An admin of a school or workplace could apply a policy over machines forcing this "feature" to be disabled. Same way Chrome now allows admins to set and lock settings options. As an extension Chrome now also allows for disabling plugins unless on a whitelist. Firefox is sure to follow.
(Score: 2) by All Your Lawn Are Belong To Us on Monday July 08 2019, @02:06PM (3 children)
How would the intermediary be able "provide the DNS itself but log it" if it doesn't have the certificate to authenticate the HTTPS session to the client browser? It wouldn't be able to see what's requested, would it? The most trapping/logging that could be performed was that Client X asked for HTTP to resource Y when resource Y is a known DNS resolver. It can block/redirect to a soft landing page where the user would be invited to re-enter the query that the intermediate will then resolve.
But I could be wrong.
This sig for rent.
(Score: 5, Informative) by jmorris on Monday July 08 2019, @02:53PM (2 children)
Captive networks (schools, Universities, corporate fleets, etc) have long inserted a local root cert allowing their filters and proxies to break https on a routine basis. Because they must, to meet a multitude of legal requirements and for sound business reasons.
My problem is I don't want to do that. I like passing my library patron traffic to sites and NOT KNOWING what is in it. If I trapped all their traffic I'd have every Amazon password, credit card number and even more personal stuff I really do not want to be responsible for safeguarding. But I also have to forbid some of the obvious naughty destinations. DNS filtering is good enough for that.
Worse though, the big trend now is patrons with phones, tablets and laptops of their own. I am NOT going to insist they install a root cert as a requirement to connect to our in house WiFi.
So DoH is a non-starter. It gets banned with extreme prejudice. If somebody has it enabled in the mode with no fallback to regular DNS we will just tell them they can't do that. If they want that level of privacy, a public WiFi is the wrong place for it. Or they can use a VPN, then when they do something naughty the Feds aren't all up in our business anyway. :)
(Score: 2) by All Your Lawn Are Belong To Us on Monday July 08 2019, @04:18PM
Thanks for the information!
This sig for rent.
(Score: 1, Informative) by Anonymous Coward on Monday July 08 2019, @08:14PM
The problem with that is that is that, according to the spec., DoH is done over HTTPS (i.e. as a GET or POST request to a magic path) on the default port of 443. The implications of that are that it is impossible to filter DoH without MiTM the HTTPS connection (and all that implies, including that you'd have to do it for all connections) or just hoping that whomever sticks to well-known IP addresses that only do DoH.
(Score: 0) by Anonymous Coward on Tuesday July 09 2019, @12:41AM
This now means assumptions you made about being secure because your /etc/resolv.conf (or windows equivalent) is controlling all non-direct IP accesses to the internet for you no longer holds true. As a result compartmentalized OSes/firewalling+proxy/etc are the only ways to secure your applications now.
As an additional concern, they mention applications hardcoding lists of urls/websites which do the dns handling for you, instead of using ones you the user specified. That means that marketing/google/facebook/etc can more easily gather and corroborate your dns queries, unlike the current system where they are normally kept at the ISP level. In addition, this doesn't help in countries with deep packet inspection, where they are already overriding the chain of authenticity in the browser in order to MITM https connections, which will result in them being able to both confirm you send a particular DNS query, as well as redirect you to a site of their choosing.
This is a huge clusterfuck all around that was not thought out at all. Reactionary projects like this are only making the Web worse, not better.
(Score: 0) by Anonymous Coward on Tuesday July 09 2019, @06:13PM
What privacy? If you use DNS over HTTPS by default CloudFlare knows ALL those dns requests.
By the time you've set stuff up to get some semblance of privacy you'd probably be reinventing a crappier version of Tor.
Might as well learn to use Tor properly if you want privacy.
(Score: 5, Insightful) by BsAtHome on Monday July 08 2019, @11:24AM (3 children)
This is actually a problem. The system settings should always be the master in configuration. Especially for something as important as low-level network services. I have nothing against DNS-over-HTTPS, but I want to be in control. I have my own local-network-wide DNS resolver and do not want applications to bypass it. How else do I get rid of farcebook that easily?
In-app service dependencies are not only a hell to manage, they pose a real threat to transparency and configurability of the network-stack. Remember how windows prevents the hosts file from blocking MS' target domains? Hidden configs are a real pain. And then, after someone finds a way to hack the app, it will all end in tears. If we want DNS over HTTPS, then it should be transparently and openly managed by the system, where the sysadmin can do the proper configuration.
(Score: 1, Interesting) by Anonymous Coward on Monday July 08 2019, @12:25PM
Lots of apps have already started hard coding the DNS servers they use. Google in particular is bad about this... it keeps you from ad filtering via something like a pi-hole and it lets them know every site you're looking at. You can fix that on your router, only given you know how and that you have access to it.
If this takes off they could just serve the requests from the same IPs as search and you won't be able to block it.
(Score: 4, Insightful) by c0lo on Monday July 08 2019, @01:00PM
For you, not for faecebook
You can't. Problem solved (well, faecebook's problem solved), you only count as a consumer that must act as a source of profit.
(grinning off)
---
Add to this a scenario involving "great firewall of [social_media_name]" - in which links to outside-Faecebook-pages posted by the "user" inside Faecebook pages are censored or redirected; and the same way for Amazon. And the same way for Disney vs. Netflix.
On the second thought... mmm... that's not a bug, that's a feature. Yeap, full steam ahead boys, the sane smaller players can't afford playing MAD games so they won't play nasty (except for the phishers)
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by darkfeline on Tuesday July 09 2019, @03:16AM
DNS is and was ALWAYS an application level protocol. Go dig up the ol' OSI chart. Where does DNS sit? Level 7, Application Layer.
The OS MAY provide name resolution as a convenience. The OS MAY provide an application configuration service as a convenience (Windows registry, anyone?). But applications have always had free reign to do whatever the hell they wanted.
Join the SDF Public Access UNIX System today!
(Score: 5, Funny) by AndyTheAbsurd on Monday July 08 2019, @12:18PM (2 children)
"Off" is the direction in which this idea should fuck, with immediacy and alacrity.
Please note my username before responding. You may have been trolled.
(Score: 0) by Anonymous Coward on Monday July 08 2019, @02:04PM
You search for "fuck off" has come back with 1,438,323 related results from fb.com and msdn.com. Search with us again!
(Score: 3, Insightful) by FatPhil on Monday July 08 2019, @03:01PM
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by zeigerpuppy on Monday July 08 2019, @01:29PM (1 child)
This seems quite easy to set up server-side.
I can see advantages for avoiding filters and metadata snooping.
Here's a good guide for Debian/Ubuntu: https://www.aaflalo.me/2018/10/tutorial-setup-dns-over-https-server/ [aaflalo.me]
(Score: 0) by Anonymous Coward on Monday July 08 2019, @08:38PM
Or you could just use DNS-over-TLS (or DTLS), which is supported out-of-the-box by most DNS servers (or could be put behind stunnel with relative ease); especially when you compare it to having new-and-untested servers doing a new and untested tunneled protocol on a three deep stack.
(Score: 4, Insightful) by Subsentient on Monday July 08 2019, @01:57PM
DNS over HTTPS? Really? DNS protocol on an SSL socket isn't good enough for you? You have to add all the crap of HTTPS on top of it instead?
This is good as a stopgap measure, but should NEVER be allowed to become the standard.
"It is no measure of health to be well adjusted to a profoundly sick society." -Jiddu Krishnamurti
(Score: 0) by Anonymous Coward on Monday July 08 2019, @01:58PM (1 child)
We have seen sneaky resolution or DNS done before [petri.com]. Didn't go down well then. Won't go down well now.
(Score: 0) by Anonymous Coward on Monday July 08 2019, @03:19PM
you are wrong, alas. this is/was a hack, no a crack (because evil), to quickly statisfy the people making by selling ads on behalf of ... well others.
muchos grandos monies is involved and if it involves turning the intertubes into sewage pipes it WILL happen!
with dnsoverhttps all simple solution of blackholing (better yet, rejecting) domains serving ads have become null and void.
with doh, the intertubs turned into a all you can eat buffet for ad companies, disguised as "freedom for all, no more blocked domains".
the real, main and singular motive is making ad-blocking impossible...
what we need now is a daemon that autoupdates all (known) doh server xor registers the first lookup of the doh server, then redirects all further request to that/those ip ranges go a local doh server we can control AND STILL BLACKHOLE/REJECT certain domains.
as far as i can tell, the doh servers in the app are still "name.dohserver.fecease.net" and not a hard ip, thus the first lookup/resolve is still regular dns to get the ip adress of "dohserver". this should trigger a redirect rule of the firewall for ip.address.dohserver to a ip of a local doh server? nevermind the blocken cert. let the user know ...
(Score: 1, Interesting) by Anonymous Coward on Monday July 08 2019, @03:21PM
This is DNS-Over-Cloudflare.
The company is the equal villain as Google. Does the same thing as Google, running malware on user's computers, blocking access to those who don't have their malware present and being American company is another part of state-level surveillance. Now we're giving it power to manipulate target servers we visit. You're from a country USA wants to attack? You will get a "special" versions of pages. Or not get at all because f... you. And you will have no way to change it.
It is true that many countries use DNS to censor Internet, but Cloudflare will do it too, it's a company so there must be only someone who will pay or threaten their profits. Giving users no choice is a bad idea.
Just as Chrome is Google's attempt to monopolize the Internet, Firefox is Cloudflare's.
The proper move to encrypt DNS will be to spread an encrypted server first, not make it dependent on one shady company.
(Score: 0) by Anonymous Coward on Wednesday July 10 2019, @04:26AM
If the DoH stuff doesn't go through the Tor network stuff then that might be a way for some Tor users to end up less anonymous...