
Android getting “DNS over TLS” support - Fake4d
https://www.xda-developers.com/android-dns-over-tls-website-privacy/
======
NaliSauce
I really like this even though I think it only makes for a minimal increase in
privacy due to either SNI[1] or quickly grabbing the cert of an IP revealing
the hostname if no SNI is supported.

[1]
[https://en.wikipedia.org/wiki/Server_Name_Indication](https://en.wikipedia.org/wiki/Server_Name_Indication)

~~~
richardjennings
SNI will show the hostname of the "DNS over TLS" server the TLS connection is
made with but not the DNS queries made.

~~~
Ajedi32
DNS isn't very useful unless you're actually planning to visit the IPs you
just looked up. And as soon as you do that, you'll send the domain name in
plaintext via SNI.

------
therealmarv
If anybody is interested for this on Desktop... here is a link to Dingo for
Google's DNS:
[https://news.ycombinator.com/item?id=12514170](https://news.ycombinator.com/item?id=12514170)

------
erpellan
Please correct me if I'm wrong, but isn't this strictly worse than DNSCurve &
DNSCrypt? Those protocols are secure even over a hostile network. The only
traffic visible is an end-to-end encrypted DNS request.

~~~
chrissnell
I don't know much about DNS over TLS but one thing I like about DNSCrypt is
the certificate pinning.

The one thing I don't really like about DNScrypt, or privacy-oriented DNS in
general, is the lack of transparency of the remote end. I wish that more of
the DNScrypt endpoints were run by organizations that I trust (EFF, etc)
instead of by some random dude out on the internet. We need a highly
transparent, non-commercial foundation for this.

~~~
jedisct1
Indeed, that would be neat.

------
gruez
Feels like placebo security to me. If the protocol is http, any attacker can
still see the domain name through the host header. Plus it does nothing to
stop them from intercepting/modifying the request/response. If the protocol is
ssl/tls the domain name is in the sni. You'll inevitably have to disable it
every time you use public wifi (to get the captive portal to show up). Using
TLS adds latency, because of the tcp handshake required (unless they're using
DTLS), and it exposes all the domain names you visit to google, so it's
actually worse than regular dns.

~~~
hannob
> Feels like placebo security to me. If the protocol is http, any attacker can
> still see the domain name through the host header. Plus it does nothing to
> stop them from intercepting/modifying the request/response. If the protocol
> is ssl/tls the domain name is in the sni.

This is an interesting argument that people have been having over and over.

Whenever someone proposes to encrypt DNS someone will come up with "but SNI
still leaks the host name". Whenever someone proposes to encrypt SNI then
surely someone will point out "DNS still leaks the host name".

Yeah, you need to encrypt both. But that fact is no argument for not
encrypting at all.

~~~
vetinari
SNI works _because_ it is not encrypted, that's the point why it was
introduced in the first place. What key are you going to use to encrypt it?

~~~
dullgiulio
In theory you don't need a key if you do a DH exchange, but I suppose that's
too many round trips and makes things generally much more complicated in the
protocol later (unless you discard the first DH-exchange, wasting even more
round-trips).

~~~
Ajedi32
DH exchange on its own isn't secure against active MITM attackers.

~~~
aaomidi
You can use a public key in the dns record and also activate dnssec.

But dnssec isn't really that secure so...

~~~
gruez
>You can use a public key in the dns record and also activate dnssec.

then you dont even need certificates, just use DANE.

------
TazeTSchnitzel
This might be big for censorship circumvention. If DNS is over TLS, it can't
be transparently proxied.

~~~
gambiting
Fantastic, hopefully it will be enough to thwart the surveillance made
mandatory in the UK recently, where ISPs have to keep a record of every
website you visit for a year.

~~~
coffee9
You won't be thwarting anything with a Google product.

~~~
gambiting
I'd rather google have my personal browsing history than the UK government.

~~~
saimiam
Yes, with pervasive CCTVs, porn filters, and Five Eyes, the UK has arguably
lost your trust and you feel company X (google in your case) more closely
aligns with your values, but you must realize that this corporatism is
corrosive to democracy.

The government is you in proxy. You can vote out the government. You can sue
it in court. You can blog about its abuses. You ARE the government.

And yet, here you are saying that you want some private company which does
business with and operates under the jurisdiction of the government to receive
and retain all your private data.

This company has no loyalty to you. Your interests are seldom in perfect
alignment with its interests. Unless securing your data serves their business
interests, they will not fight back if the UK government asks for your data.

You are introducing indirection in your interactions with your own duly
elected government and that is going to cost you your voice in the direction
the UK is headed.

~~~
gambiting
>>You can vote out the government.

My problem is that in my specific case, I can't. I lived here for 8 years but
because I don't have a British passport, I cannot vote this government out.
The government here does not represent me or care about me - so the only way I
can take care of my own future is by voting with my wallet - and I would
rather trust google with my data than the UK government. I do see your general
point though.

------
Wehrdo
The article mentions preventing ISPs from knowing which websites you visit,
but won't they still know the IP address of the server you access? Given that
websites have relatively static IPs, doesn't that make it trivial to map back
to a domain? Sorry if I'm completely misunderstanding the situation.

~~~
detaro
No, you are not misunderstanding it. (they don't even have to match the IP in
most cases, since the domain is in the request you send)

The main value of protected DNS is in stopping the provider or some other
middleman from changing the DNS responses you get, not in hiding your
requests.

~~~
Ajedi32
But if you're connecting to a site using HTTPS, would it even matter if a
middleman changed the DNS response? If they respond with the IP of the wrong
server, you'll just get a certificate error.

And if you're not using HTTPS, they don't need to mess with DNS responses;
they can serve you any content they want over any URL.

~~~
annabellish
Unless the host you're connecting to has some kind of certificate pinning in
play, typing `example.org` into your browser will make the initial request in
the clear, which can be hijacked even if it immediately bounces you to https.

~~~
Ajedi32
That's true even if the DNS response isn't hijacked though, which was the
point of my second paragraph.

------
jokoon
Good thing, but what servers do use DNS over TLS?

To be honest I don't really know who manage DNS mirrors... Is there an
existing RFC for encrypted DNS? Aren't ISPs the one who take care of mirroring
DNS servers?

~~~
james_pm
Conveniently, Google Public DNS.

"This does require the DNS you are using to have DNS over TLS support, though,
but it’s a start. Users can switch to Google’s DNS if they wish to benefit
from DNS over TLS."

Cut the ISPs out of the DNS data mining of Android users and encourage more
users to switch to Google DNS which, I assume, Google can still mine even when
using DNS over TLS because they are the provider.

~~~
icebraining
Google claims they don't log any personally identifiable information
(including IPs) long term or correlate with data from other services:
[https://developers.google.com/speed/public-
dns/privacy](https://developers.google.com/speed/public-dns/privacy)

~~~
lightswitch05
Are we talking about the same company that exploited Safari to bypass privacy
protections? [https://www.eff.org/deeplinks/2012/02/time-make-amends-
googl...](https://www.eff.org/deeplinks/2012/02/time-make-amends-google-
circumvents-privacy-settings-safari-users)

~~~
icebraining
I'm just reporting what they claim.

It's interesting, though, that the fix to that problem had been developed by
Google months before and submitted to Webkit; Apple has just not merged it
into Safari yet.

------
pjmlp
Those lucky ones to get updates are getting it.

Which currently means 0.2% of worldwide Android devices.

~~~
fermuch
But most devices will have it in the next 3 years. It's better to start today
than to never do it.

~~~
pjmlp
Outside US most people actually use their phones until they either die or get
stolen.

We aren't in 3 yearly "gratis" renewal contracts.

------
serg_chernata
Is there a way to do this on home router level?

~~~
Spivak
In what way? Do you want your router to expose a DNSoTLS endpoint to your
router's clients or do you want your router to use DNSoTLS to fetch its
results?

Both are technically possible but probably a lot of work if it must run on off
the shelf router because the firmware choices are pretty limited. It might be
easier to run your own DNS server off a Pi (or something) and have your router
point your clients there.

------
feld
DNSCrypt finally wins

~~~
jedisct1
What?

------
feelin_googley
"Users can switch to Google's DNS if they wish to benefit from DNS over TLS."

"If a different DNS service provider you decide to connect to does opt to
enable DNS over TLS, they'll get your DNS traffic instead of your ISP. DNS
requests will be encrypted, but the DNS over TLS server still gets to see your
DNS traffic, though that alone might be a step above using your ISP's servers
without TLS over DNS. At least this way, your ISP won't be able to attach your
queries to the IP you've been assigned, and thus your name."

Author makes a plug for a third party DNS provider. Third party DNS provider
also happens to sell web ads and data about users.

Author believes letting Google or other third party DNS provider see queries
is "step above" letting ISP see them.

Assuming this is true (to avoid needless arguments) but wanting more, is there
a "step above" letting a third party DNS provider log the queries?

IMO, yes, an obvious one. Running DNS cache and/or authoritative daemons on
localhost. Using a custom root.zone can be helpful.[FN1]

Is that possible on a mobile phone? No idea. Maybe it should be.

Any other options? How about running a cache and/or authoritative daemons on a
computer you can actually control. Set the mobile OS DNS settings to point to
that computer. It works. I have been doing this for many years.

FN1. Per packet encryption for DNS is also available via DNSCurve. For
example, I can make encrypted queries directly to the DNS servers for any
website that support it. I have been using DNSCurve for years as well. _It
works._ Only a small number of public websites have adopted it so far even
though it is relatively easy to set up.

Although I personally do not care for third party recursive DNS service, third
parties might provide a useful name lookup service over TLS. To illustrate, we
can use Google DNS is an example.

What if we could make queries over TLS (using HTTP) but _without using SNI_?

To start, get the IP address for the third party provider.

    
    
        dig dns.google.com
    

Let us assume hypothetically the IP address is 1.2.3.4

    
    
        curl https://1.2.3.4/resolve?name=example.com.\&type=dnskey
    

Assuming this service is still working you should receive a DNS packet as
JSON.

The reason why I think this could be useful is that we can use HTTP pipelining
to the http daemon. Example below. (No publicly available dns daemons accept
pipelining AFAIK.) Thus one can do multiple lookups by sending only a single
TCP packet.

I have never understood is why there are no publicly released DNS servers that
can accomodate multiple queries in a single UDP DNS packet. If I recall
correctly, the original DNS RFC contemplates this.

The DNS data returned via TLS (as JSON in the Google DNS example) might be
useful for instance in emergencies when DNS service is unavailable or
untrustworthy, or it might be inserted into HOSTS file or into custom zone
files served by localhost daemons. It could be useful.

    
    
       openssl s_client -tls1_2 -ign_eof \
       -connect dns.google.com:443 -verify 9 <<eof
       GET /resolve?name=example.com.\&type=dnskey HTTP/1.1^M
       Host: dns.google.com^M
       Connection: keep-alive^M
       ^M
       GET /resolve?name=example.net.\&type=dnskey HTTP/1.1^M
       Host: dns.google.com^M
       Connection: close^M
       ^M
       eof

