Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 17 submissions in the queue.
posted by martyb on Friday June 26 2020, @11:07PM   Printer-friendly
from the defeating-the-purpose-(DoH!) dept.

Talk about the fox guarding the hen house. Comcast to handle DNS-over-HTTPS for Firefox-using subscribers

Comcast has agreed to be the first home broadband internet provider to handle secure DNS-over-HTTPS queries for Firefox browser users in the US, Mozilla has announced.

This means the ISP, which has joined Moz's Trusted Recursive Resolver (TRR) Program, will perform domain-name-to-IP-address lookups for subscribers using Firefox via encrypted HTTPS channels. That prevents network eavesdroppers from snooping on DNS queries or meddling with them to redirect connections to malicious webpages.

[...] At some point in the near future, Firefox users subscribed to Comcast will use the ISP's DNS-over-HTTPS resolvers by default, though they can opt to switch to other secure DNS providers or opt-out completely.

[...] Incredibly, DNS-over-HTTPS was heralded as a way to prevent, among others, ISPs from snooping on and analyzing their subscribers' web activities to target them with adverts tailored to their interests, or sell the information as a package to advertisers and industry analysts. And yet, here's Comcast providing a DNS-over-HTTPS service for Firefox fans, allowing it to inspect and exploit their incoming queries if it so wishes. Talk about a fox guarding the hen house.

ISPs "have access to a stream of a user’s browsing history," Marshall Erwin, senior director of trust and security at, er, Mozilla, warned in November. "This is particularly concerning in light of the rollback of the broadband privacy rules, which removed guardrails for how ISPs can use your data. The same ISPs are now fighting to prevent the deployment of DNS-over-HTTPS."

Mozilla today insisted its new best buddy Comcast is going to play nice and follow the DNS privacy program's rules.


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: 0) by Anonymous Coward on Saturday June 27 2020, @03:14AM (8 children)

    by Anonymous Coward on Saturday June 27 2020, @03:14AM (#1013108)

    i don't care if dns lookups are in cleartext and can be seen on "the wall of sheep".
    what is not cool however is if the "cleartxt" lookup can be uniquely tied to me (my ip address).

    now i don't pretend to understand this DoH but i assume that whatever doh enabled server is used that it doesn't know all and each mapping of domain name-2-ip.address. thus this server has to ask another.
    now if i understand half-assed correctly, the doh server needs to ask another server thus it needs to understand the content of the request. unless everything in the chain is just hashes then somewhere in the chain the encryption needs to be stripped, processed ("is the request for .org or .net" for example) and then maybe re-encrypted.
    in any case, the problem (seee above unique mapping of dns lookup request to unique ip.address) is not solved. all that is done is painting the isp dark black and awarding a "big, central,easly subpony-ed" entity with thrust... which is bad.
    i recommend to smartly read all configuration options in torrc.

  • (Score: 1, Insightful) by Anonymous Coward on Saturday June 27 2020, @04:28AM (7 children)

    by Anonymous Coward on Saturday June 27 2020, @04:28AM (#1013136)

    If I go to www.Google.com a DNS server returns Google's IP address to my computer and my web browser connects to said IP address.

    If there is an eavesdropper and the DNS traffic is encrypted they won't be able to see what websites I am sending to the DNS server or the IP address that's being returned back to my computer.

    But when my computer gets the IP address back and my browser actually connects to said IP address then they would be able to see that I connected to Google's IP address and hence I must have requested www.Google.com. So .... they can still see what websites I am connecting to ... what's the point of encrypting DNS server traffic ... am I missing something?

    • (Score: 0) by Anonymous Coward on Saturday June 27 2020, @05:47AM

      by Anonymous Coward on Saturday June 27 2020, @05:47AM (#1013157)

      DNS hasn't been fit for the modern internet for a long while. Unfortunately, alternatives that have a chance of being accepted will probably be some google-NSA spy protocol.

    • (Score: 0) by Anonymous Coward on Saturday June 27 2020, @10:13AM (2 children)

      by Anonymous Coward on Saturday June 27 2020, @10:13AM (#1013193)

      There may be multiple websites being hosted at that IP address. If your DNS queries are encrypted the eavesdropper won't know which site you're visiting.

      • (Score: 1, Informative) by Anonymous Coward on Saturday June 27 2020, @09:30PM (1 child)

        by Anonymous Coward on Saturday June 27 2020, @09:30PM (#1013397)

        There may be multiple websites being hosted at that IP address. If your DNS queries are encrypted the eavesdropper won't know which site you're visiting.

        Er, no, virtual hosting only works at all on HTTPS because modern web browsers send the domain name unprotected during the TLS handshake (Server Name Indication). This is required because the hostname is an essential part of the TLS authentication process and typically the server must select different certificates for different hostnames. Prior to SNI virtual hosting was basically impossible with HTTPS unless you had a single certificate to cover every domain.

        Even if the server name was protected, assuming the websites hosted at that IP address are public and known to the eavesdropper then an eavesdropper who can monitor your encrypted HTTPS traffic will be able to determine exactly which website you visited on that server with very high confidence.

        This is because HTTPS does effectively nothing to obscure any of (a) the server to which you are communicating, nor (b) how much data is transferred, nor (c) the timing of the various resource requests made by your web browser.

        Those details, taken together, have high probability of being unique not just for different websites, but also individual pages within those websites. It is therefore pretty reasonable to assume that an eavesdropper will be able to know which pages you are visiting without too much trouble, even if they cannot decrypt any of your traffic.

        This is why projects like Tor exist, which actually do attempt to hide who is communicating with whom.

        • (Score: 0) by Anonymous Coward on Sunday June 28 2020, @05:04AM

          by Anonymous Coward on Sunday June 28 2020, @05:04AM (#1013570)

          Exactly. DNS, HTTP, and HTTPS were never intended to hide meta data. Encrypting the DNS traffic doesn't change this.

          TOR was intended to hide such information. As you said, TOR even introduces artificial traffic delays to make it somewhat more difficult (though not impossible) to track traffic based on timing.

    • (Score: 0) by Anonymous Coward on Saturday June 27 2020, @02:07PM (2 children)

      by Anonymous Coward on Saturday June 27 2020, @02:07PM (#1013246)

      there's a possibility that intercepting dns requests allows a middle man to redirect your request to that resolved ip to another ip (via routing) ...
      so if i can control routing and i see you resolved "google.com", and you got "1.2.3.4” i can redirect you to my 1.2.3.4 ... if i have zero day i can pawn you (some dude with scissor hands said l3tters can do this).
      they do this on the stock market too and it seems to work...

      • (Score: 0) by Anonymous Coward on Saturday June 27 2020, @09:29PM (1 child)

        by Anonymous Coward on Saturday June 27 2020, @09:29PM (#1013393)

        With a MTM attack you can see that I'm connecting to Google's IP address and redirect the traffic regardless.

        That's why, hopefully, my computer already has the necessary and correct information needed to verify that I'm connecting to Google. I can check the certificate path and make sure it's valid.

        • (Score: 0) by Anonymous Coward on Sunday June 28 2020, @05:12AM

          by Anonymous Coward on Sunday June 28 2020, @05:12AM (#1013572)

          Errr .. an MITM attack. * I didn't realize /I forgot that the in was part of the acronym