Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 18 submissions in the queue.
posted by Fnord666 on Monday July 08 2019, @10:23AM   Printer-friendly
from the Homer-Simpson-Approved dept.

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.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Interesting) by zocalo on Monday July 08 2019, @12:36PM (4 children)

    by zocalo (302) on Monday July 08 2019, @12:36PM (#864442)
    It gives end user's more *security*; the ISP can't tamper with DoH replies as easily as non-DNSSec secured DNS replies (not that too many apps throw a warning on a bad DNSSec validation), but does it really give the end user all that much extra privacy though? My feeling is a lot of people see DoH is some kind of near magical tech that *guarantees* all their web traffic is private, which is clearly not the case at all.

    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!
    Starting Score:    1  point
    Moderation   +2  
       Interesting=2, Total=2
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 4, Interesting) by Immerman on Monday July 08 2019, @01:40PM (3 children)

    by Immerman (3985) on Monday July 08 2019, @01:40PM (#864469)

    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)

      by jmorris (4844) on Monday July 08 2019, @02:45PM (#864501)

      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

        by zocalo (302) on Monday July 08 2019, @04:10PM (#864550)
        In the specific case of Cloudflare it's even worse than that. A given blocked site might resolve to a handful of IPs within Cloudflare's IP space, but in practice it seems that *any* of Cloudflare's IPs that are working as a reverse proxy will work for *any* site Cloudflare are acting as front-end host or CDN for. The only thing they seem to randomize are the IPs returned by DNS for a given site; the reverse proxy configs are much more constant and just require a valid HTTP(s) request for a site Cloudflare is currently hosting.

        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

        by Immerman (3985) on Wednesday July 10 2019, @01:41AM (#865256)

        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.