Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 17 submissions in the queue.

Android to Add 'DNS Over TLS' to Keep ISPs From Spying on You

posted by Fnord666 on Thursday October 26 2017, @04:28AM   Printer-friendly
from the DNS=Do-Not-Share dept.

MrPlow writes:

Submitted via IRC for SoyGuest31999

Android, the world's most popular mobile operating system, will soon enable a security protocol that helps keep internet service providers (ISPs) from spying on users. "DNS over TLS" adds a level of encryption to your DNS requests that are (mostly) inaccessible by your ISP.

[...] Using current methods, the requests happen through UDP or TCP protocols, not the more secure TLS. When Android makes the switch, you'll get the same results, only now with HTTPS-level security. That is to say, snoops now know when you've connected to a website, but not which one. Pornhub, for example, is the same as Gmail. Or, it is for the person spying on you. You'll still have to live with the fact you're watching Pokemon Go porn (safe-ish for work).

Source: https://thenextweb.com/mobile/2017/10/23/android-to-add-dns-over-tls-to-keep-isps-from-spying-on-you/

Original Submission

 
This discussion has been archived. No new comments can be posted.
Android to Add 'DNS Over TLS' to Keep ISPs From Spying on You | Log In/Create an Account | Top | 38 comments | Search Discussion
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: 5, Insightful) by darkfeline on Thursday October 26 2017, @07:34AM (4 children)

    by darkfeline (1030) on Thursday October 26 2017, @07:34AM (#587735) Homepage

    Can we forget privacy for a moment?

    The real win here is security, not privacy. DNS by default is completely insecure. Plaintext UDP packets. Anyone can MITM your DNS queries.

    There's stuff like DNSSEC, but a simple hack like DNS over TLS is the kind of thing DNS needs to gain wide adoption of basic security features in the current decade.

    Here's the RFC: https://tools.ietf.org/html/rfc7858 [ietf.org]

    I haven't read it yet, but it will probably be a lot more useful than TFA.

    --
    Join the SDF Public Access UNIX System today!
    Starting Score:    1  point
    Moderation   +3  
       Insightful=1, Interesting=1, Informative=1, Total=3
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  
    Total Score:   5  

  • (Score: 3, Informative) by TheRaven on Thursday October 26 2017, @10:06AM (3 children)

    by TheRaven (270) on Thursday October 26 2017, @10:06AM (#587746) Journal
    DNSSEC protects you against MITM, but I'm unsure how this is expected to. TLS protects a channel in two ways. It provides encryption, which protects you against passive snooping, but not active tampering. It also provides an out-of-band mechanism associating a host name with a connection, protecting you against active MITM, but that requires DNS to be working first. How do you bootstrap it for DNS? Scanning the RFC, it appears that there are two proposals: don't bother, or rely on some unspecified out-of-band mechanism to deliver the certificate. With the opportunistic profile, this gives you placebo security at best: MITM is trivial, and unless you have DNSSEC as well then you have no idea if the DNS resolver that you're talking to is tampering with the DNS results.
    --
    sudo mod me up

    • (Score: 2) by tibman on Thursday October 26 2017, @02:43PM (1 child)

      by tibman (134) Subscriber Badge on Thursday October 26 2017, @02:43PM (#587829)

      Out of band cert delivery most likely. Just like how it's done in your web browser today. You get certs for cert signing authorities when you install.

      --
      SN won't survive on lurkers alone. Write comments.

      • (Score: 2) by TheRaven on Thursday October 26 2017, @03:21PM

        by TheRaven (270) on Thursday October 26 2017, @03:21PM (#587839) Journal
        Web browsers contain signing certs. This is a small number[1] of certs in comparison to the number of signing certs. In contrast, the number of DNS caches that you might connect to is large and, worse, for a lot of users they're not on publicly routable IPs so you can't distribute sensible certs for them. If you're on a consumer WiFi network, the odds are that your device talks to a DNS cache that is on the 192.168/16 subnet, which then talks to an ISP-run DNS cache (which may not be on a public IP for the customer-facing side).

        You could potentially provide the cert in the DHCP response (though there's no standard for this yet), which at least means that you'd need to spoof DHCP, but that's not actually hard...

        [1] Okay, it's a large number (and a much larger number than I'm entirely comfortable with) of certs.

        --
        sudo mod me up

    • (Score: 2) by darkfeline on Thursday October 26 2017, @05:24PM

      by darkfeline (1030) on Thursday October 26 2017, @05:24PM (#587891) Homepage

      Presumably the DNS server you're using is trusted, and you have the trusted cert for that server.

      That doesn't provide end-to-end security, but let's say your trusted DNS server itself has trusted certs for other servers, and those servers have trusted certs.

      Again, it's a hack compared to DNSSEC, but it's the kind of hack that I can see getting rolled out and adopted much faster than DNSSEC has. It would be a huge improvement over the current state of affairs.

      --
      Join the SDF Public Access UNIX System today!