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.
> 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.
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.
> 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.
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).
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.
> 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".
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?
"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.
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.
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
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
"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
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.
69 comments
[ 3.4 ms ] story [ 122 ms ] threadTCP 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.
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.
But dnssec isn't really that secure so...
then you dont even need certificates, just use DANE.
It's not trying to solve the problem of privacy, only authentication.
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 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".
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?
"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.
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.
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.
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.
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.
[1] https://en.wikipedia.org/wiki/Server_Name_Indication
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
They don't replace a VPN.
Which currently means 0.2% of worldwide Android devices.
We aren't in 3 yearly "gratis" renewal contracts.
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.
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.
Your best bet is to set up your own DNScrypt service instance on your own public server running on a network that you trust.
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.
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.
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.
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.
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.
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.
"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.
Let us assume hypothetically the IP address is 1.2.3.4 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.