The one thing from the article that’s new to me and I didn’t see mentioned elsewhere:
> DNS over HTTPS offers additional tracking capabilities
> DNS over HTTPS opens up DNS to all the tracking possibilities present in HTTPS and TLS. As it stands, DNS over UDP almost always gets some free privacy by mixing all devices on a network together – an outside snooper sees a stream of queries coming from a household, a coffeeshop or even an entire office building, with no way to tie a query to any specific device or user. Such mixing of queries provides an imperfect but useful modicum of privacy.
> DNS over HTTPS however neatly separates out each device (and even each individual application on that device) to a separate query stream. This alone is worrying, as we now have individual users’ queries, but the TLS that underlies HTTPS also typically uses TLS Resumption which offers even further tracking capabilities.
> In short, setting up an encrypted connection eats up precious CPU cycles both on client and server. It is therefore possible to reuse a previously established encrypted state for subsequent connections, which saves a lot of time and processor energy.
> It does however make it possible to track an application from IP address to IP address because this TLS Resumption session ID is effectively a cookie that uniquely tracks users across network and IP address changes.
Technological solutions only lead to centralisation of snooping. Whereas before it was possible for many players to snoop on your traffic, now a few big ones do the same and it has become even harder to prevent their snooping because everything depends on them.
One wonders if the decentralised model wasn't better after all for the majority of us who aren't concerned about state level snooping since the state usually can control us in so many ways that online privacy alone isn't enough and besides implementing checks and balances upon the state can and should be done politically, since whatever individuals do technologically the state can also do, or do better, or in the worst case, ban it.
IP is bad for privacy. You cannot fix it unless you are prepared to take a massive performance hit. Decentralization is very expensive and un-guaranteed.
The solution is to use plaintext HTTP/TCP/IP and encrypt what you need over that insecure (but simple/sniffable for development on live) channel yourself if you need performance.
Countries and large (telecom) companies have their own root certificates, HTTPS has never been truly secure. SSH is better, but only after the first connect.
Everything that tries to solve things in another broad manner will fall into this category of failure or low bandwidth, just need to select the right channel for the right product.
Sure, adding additional trusted entities isn't ideal, I'll grant you that; all other things equal, I'd prefer not having to trust CloudFlare in addition to the local network, etc. But the list at the end feels a bit defeatist:
>1. Completely shut down plaintext HTTP
>2. Use encrypted DNS
>3. Deploy functional and downgrade-proof encrypted SNI
These seem like laudable goals to me. (Though is it actually necessary to completely shut down plaintext HTTP? HSTS preload gets you there on a per-domain basis, right?)
>4. Disable OCSP/make OCSP stapling mandatory, or replacing it by an alternate mechanism
So... if OCSP doesn't encrypt its requests right now, fine. But fundamentally, if you have a cert from LetsEncrypt, and you want to ask LE whether or not that cert has been revoked, is there any reason that request can't be encrypted? It seems generally tractable.
>5. Host everything (every last widget) on large content distribution networks that are able to provide generic IP addresses, that have no discoverable link to the sites they are hosting
This one is difficult, yes, but I don't think this is the only solution. Couldn't something like Tor's onion routing also do the trick? (You can use onion URLs of course, but they're not memorable - a DNS record pointing to an onion name could be.)
And after all this, who's to say you have to use CloudFlare as your DoH provider? Pick one you trust.
The problems here are solved by the same solution that VPNs use. A VPN is a central point of failure, if their logs fall into the wrong hands or are misused they fail their mission.
That's why many VPNs don't keep logs.
The no log DoH already exists: ExpressVPN, for example, has Private, zero-knowledge DNS.
Can someone please explain why there can’t be a DHCP or RA option for which DoH server to use? Why are we going out of our way to make sure the sysadmin has to configure each and every piece of software on each and every single PC rather than just set it one in a centralized location, like every other networking option?
Without a VPN sure, with a VPN,highly recommended even with centralized DoH.
Google,mozilla and cloudflare have open DoH resolvers. For a long time less than 13 orgs controlled the 13 TLD root zones. For such an infant of a protocol 3 stable open resolvers is not bad and even if it stayed this way it is noy centralized. What stops every ISP and company from hosting a recursive DoH resolver. I think people forget that open resolvers are provided at the generosity of the companies that host them. By design, your local network should provide name resolution recursively.
I really think VPN providers should also provide (open?) DoH resolvers,it helps with their privacy image and a good/fast resolver helps with their performance image.
> Without a VPN sure, with a VPN,highly recommended even with centralized DoH.
With a VPN, DoH is essentially redundant because the DNS query is already encrypted and authenticated by the VPN, assuming you're using your VPN provider's DNS resolver.
> I really think VPN providers should also provide (open?) DoH resolvers,it helps with their privacy image and a good/fast resolver helps with their performance image.
And now you're 1 step forward, 2 steps back with the VPN provider having the sum of what was previously divided between your DNS provider and your ISP. Major VPN providers become one-stop-shops for snoopers and I'd bet some of the less scrupulous ones are happy to market your data.
There's unfortunately no free lunch but how's this? Run your own recursive resolver offsite (unbound is easy to set up), connect to that over private VPN, use DNSSEC when you can.
Google / Cloudflare's centralized DNS offerings have definite privacy tradeoffs to be considered. And those tradeoffs need to be compared to the alternatives such as ISP hosted DNS or hosting one's own recursive server. This author failed to do any of that.
Should be marked 2019 - its not a retrospective of 2019, it was published in 2019.
> DNS is one of four ways in which such meta-data gets transmitted in plaintext
The author makes the argument that because DoH doesn't plug every metadata leak, we shouldn't plug any of them. This is a ridiculous argument - by this logic, we should never fix any metadata leak because it would still leave 3 unfixed. So, I guess we'll just be stuck at 4 forever.
> Using DoH to move DNS to the cloud is a specific way of using DoH that is damaging to privacy in 2019.
Why is a Google or Cloudflare server in "the cloud" while some ISP hosted server isn't in "the cloud"?
> One significant change with DoH is that the choice what to censor (or block) moves from the network operator to the browser vendor (who picks the DoH provider). If you are a privacy activist this is great, as long as you trust your browser vendor (and its government) more than your own country.
If you assume that your browser vendor is out to get you, its not clear to me how any DNS solution is going to protect your privacy.
> Crucially, this auto-configuration (be it DHCP or PPP) is not itself super-encrypted
I have no idea what "super-encrypted" means. But it sounds nice.
> I mention these two stories to show that our assumptions on oppressive regimes may be wildly off, and not represent the reality on the ground in China, Russia, Iran, Indonesia and Turkey. It is a lot of fun being an armchair imaginary political activist, but things are remarkably different if you actually live there.
The point that DoH may not solve the privacy problems of political activists in oppressive regimes may very well be true. But, in addition to being presented as just two anecdotes, the argument again boils down to: DoH doesn't solve every imaginable problem, so, we shouldn't use it to solve any problem.
> Additionally, that third party then gets a complete log per device of all DNS queries, in a way that can even be tracked across IP addresses
What alternative is being proposed here? Using an ISP's server - the ISP is also a 3rd party. Running your own recursive resolver - in that case, you leak all of the plaintext DNS requests.
> And for actual privacy on untrusted networks, nothing beats a VPN, except possibly not using hostile networks.
Except that a VPN provider is _even better_ positioned to spy on you than Google's or Cloudflare's DNS servers. And while Google and Cloudflare's DNS offerings have significant privacy considerations, a good chunk of VPN providers have unclear ownership structures often times in unclear locations and with unclear profit motivations.
The biggest point in this article was that DoH doesn't fix all of the problems so why should we do it. We have to start somewhere don't we?
Also, the user can switch their DoH provider in Firefox to a custom one if they have a PiHole setup locally or they don't trust Cloudflare. I'd argue that Cloudflare is probably more privacy-respecting than your local ISP.
[+] [-] dang|6 years ago|reply
[+] [-] oefrha|6 years ago|reply
> DNS over HTTPS offers additional tracking capabilities
> DNS over HTTPS opens up DNS to all the tracking possibilities present in HTTPS and TLS. As it stands, DNS over UDP almost always gets some free privacy by mixing all devices on a network together – an outside snooper sees a stream of queries coming from a household, a coffeeshop or even an entire office building, with no way to tie a query to any specific device or user. Such mixing of queries provides an imperfect but useful modicum of privacy.
> DNS over HTTPS however neatly separates out each device (and even each individual application on that device) to a separate query stream. This alone is worrying, as we now have individual users’ queries, but the TLS that underlies HTTPS also typically uses TLS Resumption which offers even further tracking capabilities.
> In short, setting up an encrypted connection eats up precious CPU cycles both on client and server. It is therefore possible to reuse a previously established encrypted state for subsequent connections, which saves a lot of time and processor energy.
> It does however make it possible to track an application from IP address to IP address because this TLS Resumption session ID is effectively a cookie that uniquely tracks users across network and IP address changes.
[+] [-] Santosh83|6 years ago|reply
One wonders if the decentralised model wasn't better after all for the majority of us who aren't concerned about state level snooping since the state usually can control us in so many ways that online privacy alone isn't enough and besides implementing checks and balances upon the state can and should be done politically, since whatever individuals do technologically the state can also do, or do better, or in the worst case, ban it.
[+] [-] bullen|6 years ago|reply
The solution is to use plaintext HTTP/TCP/IP and encrypt what you need over that insecure (but simple/sniffable for development on live) channel yourself if you need performance.
Countries and large (telecom) companies have their own root certificates, HTTPS has never been truly secure. SSH is better, but only after the first connect.
Everything that tries to solve things in another broad manner will fall into this category of failure or low bandwidth, just need to select the right channel for the right product.
[+] [-] ryukafalz|6 years ago|reply
>1. Completely shut down plaintext HTTP
>2. Use encrypted DNS
>3. Deploy functional and downgrade-proof encrypted SNI
These seem like laudable goals to me. (Though is it actually necessary to completely shut down plaintext HTTP? HSTS preload gets you there on a per-domain basis, right?)
>4. Disable OCSP/make OCSP stapling mandatory, or replacing it by an alternate mechanism
So... if OCSP doesn't encrypt its requests right now, fine. But fundamentally, if you have a cert from LetsEncrypt, and you want to ask LE whether or not that cert has been revoked, is there any reason that request can't be encrypted? It seems generally tractable.
>5. Host everything (every last widget) on large content distribution networks that are able to provide generic IP addresses, that have no discoverable link to the sites they are hosting
This one is difficult, yes, but I don't think this is the only solution. Couldn't something like Tor's onion routing also do the trick? (You can use onion URLs of course, but they're not memorable - a DNS record pointing to an onion name could be.)
And after all this, who's to say you have to use CloudFlare as your DoH provider? Pick one you trust.
[+] [-] keanzu|6 years ago|reply
The problems here are solved by the same solution that VPNs use. A VPN is a central point of failure, if their logs fall into the wrong hands or are misused they fail their mission.
That's why many VPNs don't keep logs.
The no log DoH already exists: ExpressVPN, for example, has Private, zero-knowledge DNS.
https://www.expressvpn.com/features/dns
[+] [-] catalogia|6 years ago|reply
[+] [-] ComputerGuru|6 years ago|reply
[+] [-] SenHeng|6 years ago|reply
[+] [-] bestes|6 years ago|reply
[+] [-] drenginian|6 years ago|reply
[+] [-] sliken|6 years ago|reply
After all if you are using a free service, you are the product.
[+] [-] Legogris|6 years ago|reply
[+] [-] badrabbit|6 years ago|reply
Google,mozilla and cloudflare have open DoH resolvers. For a long time less than 13 orgs controlled the 13 TLD root zones. For such an infant of a protocol 3 stable open resolvers is not bad and even if it stayed this way it is noy centralized. What stops every ISP and company from hosting a recursive DoH resolver. I think people forget that open resolvers are provided at the generosity of the companies that host them. By design, your local network should provide name resolution recursively.
I really think VPN providers should also provide (open?) DoH resolvers,it helps with their privacy image and a good/fast resolver helps with their performance image.
[+] [-] zrm|6 years ago|reply
With a VPN, DoH is essentially redundant because the DNS query is already encrypted and authenticated by the VPN, assuming you're using your VPN provider's DNS resolver.
[+] [-] Legogris|6 years ago|reply
And now you're 1 step forward, 2 steps back with the VPN provider having the sum of what was previously divided between your DNS provider and your ISP. Major VPN providers become one-stop-shops for snoopers and I'd bet some of the less scrupulous ones are happy to market your data.
There's unfortunately no free lunch but how's this? Run your own recursive resolver offsite (unbound is easy to set up), connect to that over private VPN, use DNSSEC when you can.
[+] [-] droithomme|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] dagenix|6 years ago|reply
Should be marked 2019 - its not a retrospective of 2019, it was published in 2019.
> DNS is one of four ways in which such meta-data gets transmitted in plaintext
The author makes the argument that because DoH doesn't plug every metadata leak, we shouldn't plug any of them. This is a ridiculous argument - by this logic, we should never fix any metadata leak because it would still leave 3 unfixed. So, I guess we'll just be stuck at 4 forever.
> Using DoH to move DNS to the cloud is a specific way of using DoH that is damaging to privacy in 2019.
Why is a Google or Cloudflare server in "the cloud" while some ISP hosted server isn't in "the cloud"?
> One significant change with DoH is that the choice what to censor (or block) moves from the network operator to the browser vendor (who picks the DoH provider). If you are a privacy activist this is great, as long as you trust your browser vendor (and its government) more than your own country.
If you assume that your browser vendor is out to get you, its not clear to me how any DNS solution is going to protect your privacy.
> Crucially, this auto-configuration (be it DHCP or PPP) is not itself super-encrypted
I have no idea what "super-encrypted" means. But it sounds nice.
> I mention these two stories to show that our assumptions on oppressive regimes may be wildly off, and not represent the reality on the ground in China, Russia, Iran, Indonesia and Turkey. It is a lot of fun being an armchair imaginary political activist, but things are remarkably different if you actually live there.
The point that DoH may not solve the privacy problems of political activists in oppressive regimes may very well be true. But, in addition to being presented as just two anecdotes, the argument again boils down to: DoH doesn't solve every imaginable problem, so, we shouldn't use it to solve any problem.
> Additionally, that third party then gets a complete log per device of all DNS queries, in a way that can even be tracked across IP addresses
What alternative is being proposed here? Using an ISP's server - the ISP is also a 3rd party. Running your own recursive resolver - in that case, you leak all of the plaintext DNS requests.
> And for actual privacy on untrusted networks, nothing beats a VPN, except possibly not using hostile networks.
Except that a VPN provider is _even better_ positioned to spy on you than Google's or Cloudflare's DNS servers. And while Google and Cloudflare's DNS offerings have significant privacy considerations, a good chunk of VPN providers have unclear ownership structures often times in unclear locations and with unclear profit motivations.
[+] [-] fastest963|6 years ago|reply
[+] [-] sliken|6 years ago|reply