Stories
Slash Boxes
Comments

SoylentNews is people

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: 2) by All Your Lawn Are Belong To Us on Monday July 08 2019, @02:06PM (3 children)

    by All Your Lawn Are Belong To Us (6553) on Monday July 08 2019, @02:06PM (#864486) Journal

    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.
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 5, Informative) by jmorris on Monday July 08 2019, @02:53PM (2 children)

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

    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

      by All Your Lawn Are Belong To Us (6553) on Monday July 08 2019, @04:18PM (#864555) Journal

      Thanks for the information!

      --
      This sig for rent.
    • (Score: 1, Informative) by Anonymous Coward on Monday July 08 2019, @08:14PM

      by Anonymous Coward on Monday July 08 2019, @08:14PM (#864676)

      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.