Experimenting with same-provider DNS-over-HTTPS upgrade(blog.chromium.org)
blog.chromium.org
Experimenting with same-provider DNS-over-HTTPS upgrade
https://blog.chromium.org/2019/09/experimenting-with-same-provider-dns.html
60 comments
> This is false, and downright dangerous information. A network attacker can still see that you are visiting pornhub.com
This won't be true as soon as ESNI gets implemented. (Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=908132 and Firefox nightlies have it already). However, ESNI is pretty meaningless if you're making plain-text DNS requests, so DoH is a pretty important part of the puzzle.
This won't be true as soon as ESNI gets implemented. (Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=908132 and Firefox nightlies have it already). However, ESNI is pretty meaningless if you're making plain-text DNS requests, so DoH is a pretty important part of the puzzle.
Browser support for ESNI is just half of the equation, you also need servers and middleboxes to support it. For example, as of December 2017, over 10% of the traffic seen by Cloudflare was still TLSv1.0: https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet...
And eSNI is not even a solution to anything, it merely pushes a bit of cleartext identification data from one protocol to another, while assuming that lots of websites share a single IP address and that it's not possible to correlate what website on the IP is used by simply observing what kind of packets are sent from a machine, which is actually pretty easy (as each website comes with connections to multiple other IPs with specific sizes of data transfer generating a unique traffic pattern).
Sure it is, you just have to consider the threat model.
Working out what website I'm browsing by doing packet analysis between my client and an IP address is vastly more difficult than just reading "www.pornhub.com" out of the SSL handshake. Despite what you think, it's not "pretty easy".
Just because a security control doesn't mitigate all risks against all threats doesn't mean it's not useful.
Working out what website I'm browsing by doing packet analysis between my client and an IP address is vastly more difficult than just reading "www.pornhub.com" out of the SSL handshake. Despite what you think, it's not "pretty easy".
Just because a security control doesn't mitigate all risks against all threats doesn't mean it's not useful.
But it's not more difficult, it's just a bit different approach, where you need to do some work besides parsing to get those patterns, i.e. visit websites. It's more work for software engineers, but not difficult work.
"It's not more difficult" is a claim that at least needs a POC.
Like, build a prototype, show it works for some set of things Cloudflare offers over eSNI today.
Otherwise this claim is hollow. If it isn't more difficult then it sure is weird that nobody does it.
Like, build a prototype, show it works for some set of things Cloudflare offers over eSNI today.
Otherwise this claim is hollow. If it isn't more difficult then it sure is weird that nobody does it.
You don't need a PoC, you can just go through research of traffic analysis to see what's out there. But you are welcome to fund a challenge for it or something like that.
No, see you're the one claiming it's "not more difficult" so if it now needs funding apparently I suggest you put up any funding you think it'll need. The ordinary person presumably would agree that it was "not more difficult" for them to afford a mansion than a shack if you're paying for it.
Let us know how expensive "not more difficult" ends up being. It'd be great to know that DoH plus eSNI made things "Not more difficult" by say $5M per target. I'd call that more difficult but I know you disagree.
Let us know how expensive "not more difficult" ends up being. It'd be great to know that DoH plus eSNI made things "Not more difficult" by say $5M per target. I'd call that more difficult but I know you disagree.
It is absolutely true, even after ESNI is implemented. Pornhub does not share their IP with anybody else so encrypted SNI doesn't help.
So we've transitioned from telling our ISP that we're visiting Pornhub, to telling our ISP and some American corporation. Great move.
What's your solution to this? Put every website behind Cloudflare?
So we've transitioned from telling our ISP that we're visiting Pornhub, to telling our ISP and some American corporation. Great move.
What's your solution to this? Put every website behind Cloudflare?
> Pornhub does not share their IP with anybody else so encrypted SNI doesn't help.
How do you know this? Do you work for them? Is that true for all time in the past and the future?
How do you know this? Do you work for them? Is that true for all time in the past and the future?
"How do you know this?"
Some 5 second basic investigation.
"Do you work for them?"
No.
"Is that true for all time in the past and the future?"
No. So what? What part of my argument don't you understand?
Also, given the reduction in privacy I just demonstrated above, what's your solution? I gave you one, which was put all websites behind cloudflare. That is a shit solution. I'm hoping you have a better one...?
Some 5 second basic investigation.
"Do you work for them?"
No.
"Is that true for all time in the past and the future?"
No. So what? What part of my argument don't you understand?
Also, given the reduction in privacy I just demonstrated above, what's your solution? I gave you one, which was put all websites behind cloudflare. That is a shit solution. I'm hoping you have a better one...?
So if you're right, then Pornhub is a bad example. I agree that ESNI won't help.
However, the reality that a large number of domains are on shared IP addresses, because they're either on some sort of CDN, or are using some sort of cloud-based load balancer etc. For these sites, ESNI certainly will make a difference. I'm not interested in an absolutist argument about how "thing" is useless because it doesn't work for a specific case. Don't let the perfect be the enemy of the good.
> Also, given the reduction in privacy I just demonstrated above
You've not demonstrated any reduction in privacy. "Privacy" as a bare concept is pretty meaningless - Privacy from whom? If I choose to give my DNS data to Cloudflare, that's my choice. Passing plaintext DNS traffic and hostnames on the wire removes my choice to restrict who I expose that data to.
> I gave you one, which was put all websites behind cloudflare. That is a shit solution. I'm hoping you have a better one...?
People have been sharing IPs on domains long before Cloudflare was invented.
However, the reality that a large number of domains are on shared IP addresses, because they're either on some sort of CDN, or are using some sort of cloud-based load balancer etc. For these sites, ESNI certainly will make a difference. I'm not interested in an absolutist argument about how "thing" is useless because it doesn't work for a specific case. Don't let the perfect be the enemy of the good.
> Also, given the reduction in privacy I just demonstrated above
You've not demonstrated any reduction in privacy. "Privacy" as a bare concept is pretty meaningless - Privacy from whom? If I choose to give my DNS data to Cloudflare, that's my choice. Passing plaintext DNS traffic and hostnames on the wire removes my choice to restrict who I expose that data to.
> I gave you one, which was put all websites behind cloudflare. That is a shit solution. I'm hoping you have a better one...?
People have been sharing IPs on domains long before Cloudflare was invented.
> So if you're right, then Pornhub is a bad example. I agree that ESNI won't help.
You need to replace "won't help", with "makes matters worse" for that to be correct.
> "However, the reality that a large number of domains are on shared IP addresses,"
Also, the reality is that a large number of domains are not on shared IP addresses.
> "You've not demonstrated any reduction in privacy"
Incorrect. It's pretty straight forward:
1. Shared IP before ESNI: Increases the number of companies that get to see which website I'm visiting.
2. Non-Shared IPs before ESNI: Increases the number of companies that get to see which website I'm visiting.
3. Shared IP after ESNI: Changes which company gets to see which website I'm visiting.
4. Non-Shared IP after ESNI: Increases the number of companies that get to see which website I'm visiting.
1, 2 and 4 are all making matters demonstratably worse. 3 only makes matters "better" if you think that Cloudflare is a better custodian of your browsing data than your ISP, which is not always the case now, and will not always be the case going forwards. And until ESNI is in place, we're stuck on 1 and 2. So in the short term, Mozilla are definitely definitely making things worse for their users.
> People have been sharing IPs on domains long before Cloudflare was invented.
Also, people have been not sharing IPs on domains longer before CLoudflare was invented, and will continue to do so after DOH is the default. So lets drop this "ESNI will fix it" argument, as it doesn't work unless we centralise the web.
You need to replace "won't help", with "makes matters worse" for that to be correct.
> "However, the reality that a large number of domains are on shared IP addresses,"
Also, the reality is that a large number of domains are not on shared IP addresses.
> "You've not demonstrated any reduction in privacy"
Incorrect. It's pretty straight forward:
1. Shared IP before ESNI: Increases the number of companies that get to see which website I'm visiting.
2. Non-Shared IPs before ESNI: Increases the number of companies that get to see which website I'm visiting.
3. Shared IP after ESNI: Changes which company gets to see which website I'm visiting.
4. Non-Shared IP after ESNI: Increases the number of companies that get to see which website I'm visiting.
1, 2 and 4 are all making matters demonstratably worse. 3 only makes matters "better" if you think that Cloudflare is a better custodian of your browsing data than your ISP, which is not always the case now, and will not always be the case going forwards. And until ESNI is in place, we're stuck on 1 and 2. So in the short term, Mozilla are definitely definitely making things worse for their users.
> People have been sharing IPs on domains long before Cloudflare was invented.
Also, people have been not sharing IPs on domains longer before CLoudflare was invented, and will continue to do so after DOH is the default. So lets drop this "ESNI will fix it" argument, as it doesn't work unless we centralise the web.
There are people and organizations that gather and store historical data on which websites resolved to which IP addresses at what time from where. Sometimes they run a service allowing you to freely query what other websites resolve to which IP addresses, like securitytrails.com does for example, where you can see that pornhub only hosts pornhub websites on its IPs.
...and you think the sequence and timing of IP addresses your machine connects to alone can't be used to easily infer the website you're browsing? Neither DoH nor ESNI will make you more secure/private, but DoH will definitely make some companies more powerful. That's not the Internet as we knew it until now.
Thankfully, today's Internet is definitely not the Internet of the early 2000s I remember – it was highly insecure and infested with virus/worms everywhere. Thanks to efforts like this Internet has gradually evolved to become more secure and more useful for real-world applications.
Both DoH+ESNI will make me more secure and private. Here's why:
Today my home ISP has deployed middle boxes that inspect my traffic to profile my browsing habits and serve me ads. They serve ads by doing click hijacking on plain http websites. yeah, it's nasty and they do it at a huge scale.
Obviously, we have some legislative gaps to address here.
Irrespective of the legal gaps, I can make it more expensive for them to do this by ensuring all of my traffic is fully encrypted (TLS 1.3 or wireguard).
They can still see IPs and do IP reverse lookup and traffic timing analysis etc. But the information leaked this way is far lesser than today and definitely not actionable immediately the way it is today.
Now, w.r.t making some companies more powerful – that is not inherent to DoH. DoH makes it possible for anyone to operate a secure and private resolver and any client is still free to choose who should be their upstream dns resolver. Client auto configuration protocols will evolve to support the ecosystem as more DoH resolvers show up.
Both DoH+ESNI will make me more secure and private. Here's why:
Today my home ISP has deployed middle boxes that inspect my traffic to profile my browsing habits and serve me ads. They serve ads by doing click hijacking on plain http websites. yeah, it's nasty and they do it at a huge scale.
Obviously, we have some legislative gaps to address here.
Irrespective of the legal gaps, I can make it more expensive for them to do this by ensuring all of my traffic is fully encrypted (TLS 1.3 or wireguard).
They can still see IPs and do IP reverse lookup and traffic timing analysis etc. But the information leaked this way is far lesser than today and definitely not actionable immediately the way it is today.
Now, w.r.t making some companies more powerful – that is not inherent to DoH. DoH makes it possible for anyone to operate a secure and private resolver and any client is still free to choose who should be their upstream dns resolver. Client auto configuration protocols will evolve to support the ecosystem as more DoH resolvers show up.
The only reason that security conscious web sites haven't implemented any traffic analysis countermeasures is that the stuff leaks out in cleartext anyway. After DoH and ESNI are implemented, I can imagine many relatively cheap approaches that websites can use to make traffic analysis a few notches harder.
They could easily have said "DoH, combined with other future technologies, would prevent other WiFi users from seeing which websites you visit"
I agree with you.
However this claim could be true in the future if/when Encrypted SNI (ESNI) for TLS 1.3 is deployed. Although ESNI is at the draft stage [1] and to the best of my knowledge is not at a deployable stage yet.
However it might be finalized and deployed by the time DoH for Chrome is finalized too ?
[1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
However this claim could be true in the future if/when Encrypted SNI (ESNI) for TLS 1.3 is deployed. Although ESNI is at the draft stage [1] and to the best of my knowledge is not at a deployable stage yet.
However it might be finalized and deployed by the time DoH for Chrome is finalized too ?
[1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
This might be encrypted too in the future. https://tools.ietf.org/html/draft-ietf-tls-esni-04
Long story short: Chrome will do DoH DNS, but only if your current DNS provider already supports DoH, and, for now, only as an experimental feature.
People are upset about Firefox's new default of routing DoH to Cloud Flare, and I understand why. But it's useful to keep the issues distinct: DoH is a good thing (your ISP should not be able to see your DNS queries), even if routing them to Cloud Flare isn't.
People are upset about Firefox's new default of routing DoH to Cloud Flare, and I understand why. But it's useful to keep the issues distinct: DoH is a good thing (your ISP should not be able to see your DNS queries), even if routing them to Cloud Flare isn't.
DoH is a good thing when I configure it on a system level. Each individual app bypassing the system DNS settings to implement DoH within the app is not a good thing.
As a thought exercise: why is the OS level the correct level for DNS configuration? Why would the LAN not own this?
It seems interesting that the article and many comments here identify the application level as inherently wrong and the OS level as inherently right.
What if you were running docker containers on a server?Is it incorrect for the containers to set their own resolver settings?
It seems interesting that the article and many comments here identify the application level as inherently wrong and the OS level as inherently right.
What if you were running docker containers on a server?Is it incorrect for the containers to set their own resolver settings?
> Is it incorrect for the containers to set their own resolver settings?
For generic containers, it is. If you build your own very customised app, then sure, you can control what it does. But if you build an app, you don't know where/how I deploy it. It may be without internet access. It may be expected to use private DNS zones. It may be expected to query mdns. The container should not guess or assume those things.
For generic containers, it is. If you build your own very customised app, then sure, you can control what it does. But if you build an app, you don't know where/how I deploy it. It may be without internet access. It may be expected to use private DNS zones. It may be expected to query mdns. The container should not guess or assume those things.
I think I agree with you, but also I think I feel the same way about generic computers. I’d say that outside of specialized use cases, the OS is the wrong layer to define DNS settings: the network is the correct layer. Because that means that as computers move between networks, they handle things like private zones.
That said, I also think that there’s no absolute truth for what constitutes a “specialized use case”. I think if I’m the operator of a network, or a computer, or a container, or an application, having it use custom DNS settings is up to me. And Firefox/Chrome enable that: the operator can change the setting to whatever they want.
Speaking to the default case, Firefox/Chrome moving towards DNS defined at the app layer smells painful to me as a network operator, but ISP DNS interception also smells to me, and for the normal consumer threat model and network topology, Firefox/Chrome using CloudFlare DNS is essentially pure win. Most consumer users aren’t on networks with split-horizon DNS, and most consumer users aren’t at risk from CloudFlare logging their DNS requests, even assuming they’re violating their published privacy policies.
That said, I also think that there’s no absolute truth for what constitutes a “specialized use case”. I think if I’m the operator of a network, or a computer, or a container, or an application, having it use custom DNS settings is up to me. And Firefox/Chrome enable that: the operator can change the setting to whatever they want.
Speaking to the default case, Firefox/Chrome moving towards DNS defined at the app layer smells painful to me as a network operator, but ISP DNS interception also smells to me, and for the normal consumer threat model and network topology, Firefox/Chrome using CloudFlare DNS is essentially pure win. Most consumer users aren’t on networks with split-horizon DNS, and most consumer users aren’t at risk from CloudFlare logging their DNS requests, even assuming they’re violating their published privacy policies.
What is a good alternative to Cloudflare? What should we change the Firefox default setting to?
A tor client that only passes DNS traffic and nothing more. But does it exist?
On this topic: I recently learned about https://support.mozilla.org/en-US/kb/configuring-networks-di...
Is this just a Mozilla one man show or are there plans by anyone else to support this? Maybe make this a standard? Some googling revealed nothing... Now the way Google does it sounds somewhat reasonable but who knows what the future will bring, or what other software will adapt DoH.
Is this just a Mozilla one man show or are there plans by anyone else to support this? Maybe make this a standard? Some googling revealed nothing... Now the way Google does it sounds somewhat reasonable but who knows what the future will bring, or what other software will adapt DoH.
The text on https://use-application-dns.net/ says that it will be attempted to become a standard through the IETF. But only time will tell.
Google make this point which I haven't seen in any of the arguments so far:
> In particular, we are aware of how DNS can play an important role in ISP-provided family-safe content filtering.
Lots of families with children use their ISP's safe browsing facilities which is usually implemented via alternative DNS servers.
Yes it is not terribly difficult to defeat, but it is cheap and effective for small and non technical children.
This does at least seem like a more sensible experiment than Mozilla's which will break the above scheme for every Firefox user.
> In particular, we are aware of how DNS can play an important role in ISP-provided family-safe content filtering.
Lots of families with children use their ISP's safe browsing facilities which is usually implemented via alternative DNS servers.
Yes it is not terribly difficult to defeat, but it is cheap and effective for small and non technical children.
This does at least seem like a more sensible experiment than Mozilla's which will break the above scheme for every Firefox user.
They address it in https://blog.mozilla.org/futurereleases/2019/07/31/dns-over-....
They say it will be enabled only for providers supporting this. Do they mean DNS servers supporting DoH?
If a network DHCP server publishes a local DNS server that is not on the list, DNS traffic will not bt encrypted?
So a network operator wishing to continue spying on its users just needs a local DNS proxy?
If a network DHCP server publishes a local DNS server that is not on the list, DNS traffic will not bt encrypted?
So a network operator wishing to continue spying on its users just needs a local DNS proxy?
> They say it will be enabled only for providers supporting this. Do they mean DNS servers supporting DoH?
No, they say providers, and mean providers. They are starting their experiment with a whitelist:
* https://www.chromium.org/developers/dns-over-https
If you're already using one of those then Chrome/ium will change from "plain DNS" over to DoH. If you are not using one of them already, then nothing will change.
No, they say providers, and mean providers. They are starting their experiment with a whitelist:
* https://www.chromium.org/developers/dns-over-https
If you're already using one of those then Chrome/ium will change from "plain DNS" over to DoH. If you are not using one of them already, then nothing will change.
Archived copy that can be read without JS enabled:
https://archive.is/59JCD
https://archive.is/59JCD
I'd be interested to know if this will affect the ability of things like Pi Hole to block advertising and user tracking via DNS?
I'm sure Pi Hole will have DoH support, so it should be fine as long as you can still change the server (in the browser and/or OS). The only snag might be mobile apps, in case they hardcode a DNS/DoH server instead of using the system config; that may be hard to change without rooting the device.
> I'm sure Pi Hole will have DoH support ...
We'll see.
Pi Hole uses DNSmasq as its DNS (and DHCP) server, and the few DNSmasq mailing list threads I've seen on the topic seem to indicate that the DNSmasq developers are not interested in either DoT or DoH. One said that it would be difficult to implement because of architectural issues IIRC.
It may be necessary to use a front-end proxy:
* https://dnsdist.org/
We'll see.
Pi Hole uses DNSmasq as its DNS (and DHCP) server, and the few DNSmasq mailing list threads I've seen on the topic seem to indicate that the DNSmasq developers are not interested in either DoT or DoH. One said that it would be difficult to implement because of architectural issues IIRC.
It may be necessary to use a front-end proxy:
* https://dnsdist.org/
DNSmasq needs to be replaced with something more secure in any event. Hopefully implemented in a memory-safe programming language.
https://www.cvedetails.com/vulnerability-list.php?vendor_id=...
https://www.cvedetails.com/vulnerability-list.php?vendor_id=...
PiHole has already merged a patch[1] to disable DoH via the global canary[2].
[1] https://github.com/pi-hole/pi-hole/pull/2915 [2] https://use-application-dns.net/
[1] https://github.com/pi-hole/pi-hole/pull/2915 [2] https://use-application-dns.net/
Pi Hole already has documentation on how to use DoH with it, and it already works:
https://docs.pi-hole.net/guides/dns-over-https/
Note: this is using cloudflared but that's just a DoH, it can and happily will query whatever provider you tell it to.
https://docs.pi-hole.net/guides/dns-over-https/
Note: this is using cloudflared but that's just a DoH, it can and happily will query whatever provider you tell it to.
That's for upstream queries, I think we're talking about the connection from the devices to the PiHole.
DoH won't become required for many years yet.
The only thing DoH gives anybody .. is even more of your private data to a centralized provider with questionable ethics, and the only company more ethically questionable than Google is Palantir. Run your own local resolver and move on with your life.
> ... private data to a centralized provider with questionable ethics
What, like your ISP?
What, like your ISP?
[deleted]
Not everybody lives in the US. I trust my ISP. They are cool, and their handling of my data is regulated under the GDPR and other laws. CloudFlare? Not so much.
I am also not in the US. However, everywhere I look I see large ISPs with questionable ethics who are centralized providers of DNS.
I'm struggling to see why DoH means "is even more of your private data to a centralized provider with questionable ethics", which is what the OP said.
I'm struggling to see why DoH means "is even more of your private data to a centralized provider with questionable ethics", which is what the OP said.
Mozilla is rolling this out in the US, where there are few ISPs across the nation.
Rather than putting real effort into this, I'm just going to say that Paul Vixie, the creator of DNS, advocates for using a local resolver (not your ISP's resolver), and DNSSEC. The internet is supposed to be decentralized, not centralized.
Cloudflare, Google, and all of these other centralized dns/ntp services are hazardous to our health.
I'm sure you're very knowledgable, but if Paul gives DNS advice, listen to him.
Cloudflare, Google, and all of these other centralized dns/ntp services are hazardous to our health.
I'm sure you're very knowledgable, but if Paul gives DNS advice, listen to him.
> Rather than putting real effort into this
Ah, you're too busy to make the case. Aren't we all.
> DNSSEC. The internet is supposed to be decentralized, not centralized.
DNSSEC centralises the DNS system with governments.
> Cloudflare, Google, and all of these other centralized dns/ntp services are hazardous to our health.
Saying it doesn't make it so.
> I'm sure you're very knowledgable, but if Paul gives DNS advice, listen to him.
I'm familiar with Paul's view. Given that most people can't or won't run a local resolver, how does it help?
Ah, you're too busy to make the case. Aren't we all.
> DNSSEC. The internet is supposed to be decentralized, not centralized.
DNSSEC centralises the DNS system with governments.
> Cloudflare, Google, and all of these other centralized dns/ntp services are hazardous to our health.
Saying it doesn't make it so.
> I'm sure you're very knowledgable, but if Paul gives DNS advice, listen to him.
I'm familiar with Paul's view. Given that most people can't or won't run a local resolver, how does it help?
Does anyone know how much money Mozilla gets from Cloudflare? Do they get any? I've tried to find something in Mozilla financial declarations but haven't found anything.
Might sound like a conspiracy, but yes, I think they are getting money. They are definitely not sending the entire browsing history of users (DoH) and even the contents (VPN[]) to CloudFlare and getting nothing in return... right?
[] https://news.ycombinator.com/item?id=20927832
[] https://news.ycombinator.com/item?id=20927832
I'm not in the business of data, so I don't know what the browsing habit of millions of people are worth.
This is false, and downright dangerous information. A network attacker can still see that you are visiting pornhub.com even with DoH, since you are sending the hostname in cleartext as part of the TLS handshake.
Google isn't a snake-oil security solution - they shouldn't be making such false claims.