Android getting “DNS over TLS” support(xda-developers.com)
xda-developers.com
Android getting “DNS over TLS” support
https://www.xda-developers.com/android-dns-over-tls-website-privacy/
69 comments
DNS-over-TLS and DNSCrypt are more about authentication than privacy. They are useful against the guy sitting behind you at Starbucks doing DNS injection.
They don't replace a VPN.
They don't replace a VPN.
SNI will show the hostname of the "DNS over TLS" server the TLS connection is made with but not the DNS queries made.
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.
It will also show the hostname of the server I access after doing the DNS lookup.
I don't think so.
The purpose of SNI is to pass the domain name to the final destination server, so it can serve up the correct SSL cert where there are multiple domains hosted on the same IP
The purpose of SNI is to pass the domain name to the final destination server, so it can serve up the correct SSL cert where there are multiple domains hosted on the same IP
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
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.
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.
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.
Indeed, that would be neat.
If you need something that works everytime, you're stuck with http and https due to outbound firewalls. Even installing a dns recursor on your laptop might not work.
I'm tempted to setup a corporate-y network as a weekend project, I think I'm getting out of touch with what some people have to bear with.
I'm tempted to setup a corporate-y network as a weekend project, I think I'm getting out of touch with what some people have to bear with.
A recursive DNS server on your laptop does next to nothing for privacy. It's still sending out the requests in plaintext to the root and authoritative nameservers. The only time it might help you is if the name is cached and it doesn't have to go to the wire to resolve it.
Your best bet is to set up your own DNScrypt service instance on your own public server running on a network that you trust.
Your best bet is to set up your own DNScrypt service instance on your own public server running on a network that you trust.
[deleted]
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.
> 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.
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.
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?
See lengthy discussions on the tls-wg list.
What definitely works is opportunistic encryption of the SNI name. You could also build something where that is later authenticated with the server's key and you could raise an alarm if it isn't. Or you could re-use a previously used session key for at least all resumed sessions. Yeah, not perfect, but better than nothing.
What definitely works is opportunistic encryption of the SNI name. You could also build something where that is later authenticated with the server's key and you could raise an alarm if it isn't. Or you could re-use a previously used session key for at least all resumed sessions. Yeah, not perfect, but better than nothing.
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).
DH exchange on its own isn't secure against active MITM attackers.
You can use a public key in the dns record and also activate dnssec.
But dnssec isn't really that secure so...
But dnssec isn't really that secure so...
> Using TLS adds latency, because of the tcp handshake required
TCP Fast Open gets rid of the TCP handshake latency, but even with TLS session ids-or-tickets there is still a round-trip for ServerHello — presumably because the standardization bodies don't trust that the client is ever capable of avoiding nonce reuse or generating a secure random number.
Keeping the TCP+TLS connection alive might be feasible but you will either have to spend a lot of energy transmitting frequent keep-alive packets or run into problems on IPv4 if the network provider discards NAT mappings faster than your send interval.
Unfortunately the adoption of both RFCs is really poor, with TCP Fast Open not working with Chrome on Linux (I have it set to enable in developer settings, and it does work in Firefox) and nginx still not supporting proper session ticket key rollover.
TCP Fast Open gets rid of the TCP handshake latency, but even with TLS session ids-or-tickets there is still a round-trip for ServerHello — presumably because the standardization bodies don't trust that the client is ever capable of avoiding nonce reuse or generating a secure random number.
Keeping the TCP+TLS connection alive might be feasible but you will either have to spend a lot of energy transmitting frequent keep-alive packets or run into problems on IPv4 if the network provider discards NAT mappings faster than your send interval.
Unfortunately the adoption of both RFCs is really poor, with TCP Fast Open not working with Chrome on Linux (I have it set to enable in developer settings, and it does work in Firefox) and nginx still not supporting proper session ticket key rollover.
> You'll inevitably have to disable it every time you use public wifi (to get the captive portal to show up).
In my experience, captive portals use a MITM on HTTP connections, not a DNS hijack. If they hijacked the DNS request, the browser's DNS cache would keep the wrong response, breaking access to the real website even after login to the captive portal.
> 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.
The TCP handshake latency would be only on the first request, the same connection can be reused for further queries, especially if you are using a single recursive resolver for all queries, which is the case if it "exposes all the domain names you visit to google".
In my experience, captive portals use a MITM on HTTP connections, not a DNS hijack. If they hijacked the DNS request, the browser's DNS cache would keep the wrong response, breaking access to the real website even after login to the captive portal.
> 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.
The TCP handshake latency would be only on the first request, the same connection can be reused for further queries, especially if you are using a single recursive resolver for all queries, which is the case if it "exposes all the domain names you visit to google".
Placebo for what? It is just another way to bring you some privacy about your DNS activity /like DNSCrypt does too) and a way for you as client to simply validate DNSSEC end-to-end.
your argumentation reads like the disadvantages of HTTP vs. HTTPS. Latency issues have been mostly resolved... it's not 1999.
This might be big for censorship circumvention. If DNS is over TLS, it can't be transparently proxied.
How would transparent proxies prevented?
Proxy would need a cert trusted by the client. Not impossible, but raises the bar.
In an Enterprise or provider-patched device, this is trivial.
Yes, that's true, but I think we have to assume the Enterprise devices are mitm'd. Carrier provided devices are a legitimate threat, I agree
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.
You won't be thwarting anything with a Google product.
I'd rather google have my personal browsing history than the UK government.
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.
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.
>>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.
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.
You are ignoring both minority issues and the fact that many of us are not eligible to vote in our country of residence.
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.
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.
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.
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.
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.
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.
That's true even if the DNS response isn't hijacked though, which was the point of my second paragraph.
DNSSEC does that too...
I thought DNSSEC only has value when the queried domain has it enabled, but I might be confusing things?
You're correct.
DNS-over-TLS secures you<-->resolver; DNSSEC secures validating-resolver<-->authority, essentially. If your resolver is validating, then it secures you<-->authority.
Point being DNSSEC can be used to secure more hops than DNS-over-TLS, but DNS-over-TLS can secure the last hop without any opt-in by the domain owner.
DNS-over-TLS secures you<-->resolver; DNSSEC secures validating-resolver<-->authority, essentially. If your resolver is validating, then it secures you<-->authority.
Point being DNSSEC can be used to secure more hops than DNS-over-TLS, but DNS-over-TLS can secure the last hop without any opt-in by the domain owner.
Well, yes, but it'd be nice to get to where it's universally enabled.
EDIT: Also, DNSSEC gives you something the ohter things don't: authenticated data, including authenticated non-existence. That's a big deal.
Of course, DJB's DNS encryption would also give you privacy. Add DANE and drop SNI and you'd have privacy protection, especially if PTR RRs had nothing useful or weren't used at all for the sites you visit.
EDIT: Also, DNSSEC gives you something the ohter things don't: authenticated data, including authenticated non-existence. That's a big deal.
Of course, DJB's DNS encryption would also give you privacy. Add DANE and drop SNI and you'd have privacy protection, especially if PTR RRs had nothing useful or weren't used at all for the sites you visit.
Yes, unless you are using a VPN or Tor, the IP of the site you're connecting to is present in every TCP/UDP/ICMP packet you send out.
For some sites that are hosted on big virtual host IPs with dozens/hundreds of sites being served from the same IP, it's slightly more vague. For big sites where there is a 1:1 relationship between website and IP, there is no question about what you're visiting.
For some sites that are hosted on big virtual host IPs with dozens/hundreds of sites being served from the same IP, it's slightly more vague. For big sites where there is a 1:1 relationship between website and IP, there is no question about what you're visiting.
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?
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?
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.
"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.
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
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...
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.
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.
As with most things with Google... it first seems a benefit for the users but always helps them (Google).
They take the data away from someone but it actually helps them (Look at AMP pages). In this case it is highly likely all DNS requests will be onto 8.8.8.8 and 8.8.4.4 DNS servers - giving them more info on what you are doing when no on their own services.
They take the data away from someone but it actually helps them (Look at AMP pages). In this case it is highly likely all DNS requests will be onto 8.8.8.8 and 8.8.4.4 DNS servers - giving them more info on what you are doing when no on their own services.
https://dnscrypt.org/ is a fairly good source for servers that support the dnscrypt protocol (assuming this is what's being used - it may be a different protocol, but dnscrypt has been in the wild for some time). Not to be confused with DNSSEC
this is not DNS over TLS. It's its own crypto standard but pretty similar to DNS over TLS.
Uncensorer DNS supports it:
https://blog.uncensoreddns.org/blog/32-dns-over-tls-pubkey-p...
Those lucky ones to get updates are getting it.
Which currently means 0.2% of worldwide Android devices.
Which currently means 0.2% of worldwide Android devices.
[deleted]
Is there a way to do this on home router level?
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.
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.
Alternatively install OpenDNS Umbrella which will do this with DNSCrypt to the OpenDNS servers
"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.
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.
"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
curl https://1.2.3.4/resolve?name=example.com.\&type=dnskey
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
[1] https://en.wikipedia.org/wiki/Server_Name_Indication