So... for circumventing censorship, then?
"Was" is the correct word to use. Here's a fun example: try explaining to someone non-technical why you can't simply download your e-mails. I went through that exercise this morning, when my wife asked me to download a bunch of e-mails and send them to her in a "folder", which she can then send to someone else.
So then I had to explain that GMail allows me to download a single message -- no bulk downloads, of course -- but it saves it in .eml format, which you can't open with programs that come installed on a typical Windows box. And even if you could, there's no guarantee that the guy you're sending them to can.
Of course, she thought that was stupid: why offer saving e-mails in an "obscure" format? So I had to explain why the Internet is now a bunch of walled gardens and closed services, all built on top of open and standardized protocols and formats. And, of course, those open standards can't improve and evolve easily, because each player in the game wants to lock users and their data inside their own walled garden.
So yeah, the takeaway in a nutshell is that the Internet was once open, but then it became lucrative.
EDIT: I think a lot of people replying here might be missing the point. Like I stated above, I was trying to explain the situation to a non-technical person. Yes, I'm aware of POP and IMAP support. Yes, I know RFC5322 is not an obscure format. But I'm talking about people who don't know or care what these things are. Try downloading a bunch of messages in RFC5322 format, zipping them and sending them to your average lawyer and see how they react.
What is an obscure format is whatever Microsoft Outlook uses to store emails: https://en.wikipedia.org/wiki/Personal_Storage_Table
I can confirm that Google thinks the fact that they can't rate limiter IMAP with the same efficacy as their own APIs is a "bug".
In addition, if you're trying to download email via a web browser you're going about it the wrong way.
She probably still can't open the file in a typical Windows box, since it doesn't come with a decent email application, but MBOX is as standard as it comes.
Cloudflare (which has somewhat shady ties to us govt maybe) is pushing hard for DNS over secure channel and it's pissing off ISP's. Because they won't be able to sell personalized browsing history if is catches on....
Control/view of DNS requests is worth A LOT of money to advertisers/ISP's because it's currently immune to ad blockers and ties a user directly to their IP and real info. It's even better than browsing history because it includes everything a user does outside the browser as well, protocol agnostic, cross device.
It's the perfect example of "metadata" that various companies and agencies collect for all sorts of shitty reasons. It's the last cleartext frontier of activity monitoring.
They don't get the domain names, but for the very popular web properties that all these analytics care about calculating your relationship to, they don't need them; the IP is enough to discern which site you're visiting.
When they are providing internet content to UK customers, they must respect UK law. It's a dangerous chicken game to think UK will not be able to enforce it's laws against Cloudflare.
The villain here is the UK govt. ISPs should applaud the technical developments with all their hearts since they are legally off the hook.
DNS over HTTPS means that you can make a tv that resolves dns using https://8.8.8.8 and looks at fancy.ads. But I can't mitm it because I don't have a suitable trusted certificate to respond to that request. So either the request to fancy.ads gets dropped and the request to online.movies.example.com gets dropped so I can't use my smart tv for its intended purpose. Or both get through.
Obviously things are different if the service uses standard OS level configuration so I can tell it to resolve dns using https://my.adblocked.dns or /etc/hosts. But nothing obliges any particular system to do that.
If my logic is faulty, please, do inform.
Uponcoffee suggests inspecting the SNI header to drop the TLS handshake. So the DNS resolves fine, but when they try to connect to https://fancy.ads, that request is tampered with and fails. As far as I know, that depends on a bug in TLS which will be fixed in some future version, so that inspecting such a request becomes impossible.
NegativeLatency suggests installing an alternative certificate. This would presumably work if I have root access to my smart device. Maybe I can get access to root on my smart tv, I'm not sure, I don't use smart tvs.
But random people can't get access to root on their phone. It will break their banking apps. I can install an adblocker on my phone and accept the consequences of my actions. I'm not sure what the tradeoff between adblocking and banking apps is, even for me. I would probably want to write my own browser based app to let me log into my bank from an separated web browser - if I'm trying to log into my bank when I'm standing in the queue I don't want to piss fart around with stupid browser tabs.
I certainly can't tell my coworker "yeah I'll just install this ad blocker on your phone, it'll block some analytics too so your privacy will be a little more respected" if the only way to do it is to break their banking apps.
I mean, okay, the ads aren't unblockable. But we are at the point where I have to make a trade off between letting you run whatever code you want on my phone, and letting you not run any code at all on my phone. Capitalism depends on negotiation to work. If it's just "I'm a big company, use my service or don't", capitalism stops working.
Then there's the option to reverse lookup the dns record associated with a given ip.
So ad blocking/censorship will still be viable for a while yet.
Suggesting that we should weaken encryption/privacy because some people plan to use it in ways that we don't like is just not a viable option. It's exactly the argument that governments are trying to use to mandate backdoors in our chat services. With encryption, it's all or nothing.
I would presume that, like with DNS over DNS¹, a resolver could check /etc/hosts first prior to attempting to resolve over the network; do proposed DoH resolvers not do that?
Worse comes to worse, you could always run your own local resolver.
¹or whatever we're calling the original protocol now
How do you like them ads?
Update: https://www.flatpanelshd.com/news.php?id=1416894724&subactio...
You have no evidence that the devices would be more expensive. Your only evidence is that the companies would receive less income all else being equal. But what is the evidence that the trade off is your eyeballs instead of your dollars? And if the tv is perfect except for the ads, where do you get the more expensive, ad free version?
DNS filters might be very easy to set up but if they become more major they can be outsmarted very easily - what if Google starts serving ads from www.google.com, would you block that domain name too? Browser extensions can block content far more precisely.
And smart TVs and such stuff could easily switch resolvers and just not use your Pihole's DNS resolver - that would work even without DoH as long as you don't intercept traffic on your router. E.g. Fire TV already adds Google DNS as an additional DNS server (you can't change that). Chromecast only uses Google DNS (AFAIK you can't change that either). I guess the only viable option here is just not to buy those products.
And devices are handed DNS servers (with the option to opt out) via DHCP when they connect to the LAN.
If Cloudflare starts serving DNS traffic from HTTPS on its CDN, the malware can use Cloudflare for DNS. Am I supposed to block all of Cloudflare's IPs because they can be used to circumvent DNS query monitoring?
If it needs to phone home or otherwise contact an outside address (excluding hard-coded IP addresses), then presumably it needs it needs to do a DNS look-up at some point.
Many botnets use pseudo-random DNS domains, and when the generation algorithm was figured out, people were able to get control of it:
One DNSmasq already addresses in part through various asblock and malware-blocking DNS blacklists. I'm using one such that updates hourly or better. Requests to or for specific domains my be blocked (and are).
Keep in mind that by using DNSmasq at a centralised LAN server, you now have a single point of control to defend against such threats, rather than relying on multiple device- and application-specific points of control. Though software (such as browsers) offerring its own defences against such threats is in no way hindered.
You can further, and more appropriately IMO, defend against such threats at the firewall level, by blocking network space (rather than domains) and ports associated with malware. At the OS level, firewalls such as Little Snitch monitor and block traffic at the application / process and user level, and may detect, alert on, and/or block such malware.
As does DNS-over-TLS. Though since it has an official IANA port, this can be blocked.
> You can further, and more appropriately IMO, defend against such threats at the firewall level, by blocking network space (rather than domains) and ports associated with malware.
And if malware leverages Cloudflare, am I supposed to block that? The ports associated with malware may be HTTPS.
You seem to be manufacturing a hypothetical threat that isn't actually impacted by DoH, to no clear end.
Malware already exploits specific IP spaces (DUL, datacentres, AWS), and ports (20, 22, 25, 53, 80, 443, ...), as well as vectors such as adtech networks, IFRAME, and XHR. Those are blocked as best as possible, leveraging numerous signature, to varying degrees of effectiveness.
Methods are not perfect. But if they on net reduce or manage risks more effectively, they're a net win.
Again, DoH, either in the browser or at the LAN level, addresses a specific set of known risks. And I'm not seeing the caveats you're suggesting as either more severe or non-mitigable.
0 = use whatever the default is (one of the below)
1 = race DoH and regular dns and use whichever replies first
2 = try DoH and then fall back to regular dns
3 = only DoH
4 = unused
5 = explicitly off
The default resolver is identical to 1.1.1.1 except it collects less data: https://developers.cloudflare.com/1.1.1.1/commitment-to-priv...
It's not so bad, because HTTPS supports keep-alive, so you can make a bunch of queries with a single TLS handshake.
For a random third party that might still be slow but Mozilla and Cloudflare have every reason to do every trick that's safe to speed this up, including 0RTT TLS because replaying DNS queries isn't a problem.
How do you do split-horizon DNS if the browser goes out to some random IP for DNS instead of using the OS-supplised resolver (resolv.conf)?
If malware starts using it to contact C&C servers, how do I find the domain that's being talked to? If malware has to talk to internal DNS servers, I can examine the query log. If the malware uses Cloudflares CDN IPs for DNS, am I supposed to block all of Cloudflare?
The point is "DNS is not the only way and malware authors have known and used this fact". The counter-convenience you seem to be looking for — to quote your prior statement, with added emphasis: "If malware has to talk to internal DNS servers ..." — was never there in the first place. No matter how hard you try, there is no way you can force all malware ever to always talk to your internal DNS servers.
I don't know about ISPs, but as someone in IT, DoH could be a mess. If Firefox ignores resolve.conf how is split-horizon going to work? Wait until malware starts using it and it can't be blocked with blacklisting, e.g., entire CDN IP ranges.
Paul Vixie has strong views on DoH:
* https://twitter.com/paulvixie
I'd be okay if they at least used DNS-over-TLS (DoT): privacy and it can at least be handled by firewalls for us corporate types.
If you need malware to be nice and use your configured security systems or else it'll cause problems I have bad news for you: the malware authors aren't on your side.
Everything DoH, eSNI, TLS 1.3 and QUIC and a dozen other protocols are doing was already trivial for malware to do if it wanted. If your defences begin by assuming bad guys are only doing things that obey all your rules you've fundamentally misunderstood what "bad guys" even are.
We have a bunch of internal-only 10.x hosts and services. Why would we put them in our external DNS?
> If you need malware to be nice and use your configured security systems or else it'll cause problems I have bad news for you: the malware authors aren't on your side.
I don't. But if I see DNS traffic flowing from systems that are not our internal DNS servers, I know to look at them.
It's the same reason SMTP traffic was bottlenecked: everything goes through relays so it can be monitored.
> If your defences begin by assuming bad guys are only doing things that obey all your rules you've fundamentally misunderstood what "bad guys" even are.
Defences begin with observation. With DoH you can't tell what's going on with regards to queries. I'd much rather have DoT: still gives privacy, but since it has its own port, then it can be dealt with more easily. Of course having an IANA-assigned port allows for ISP/government filtering.
I do not, however, dismiss the UK’s argument that society needs a practical way to for parents to monitor and potentially filter what type of content their children are encountering online. I do not believe a child deserves the same privacy as a grown adult. It’s not even really arguable: it’s a parent’s responsibility to parent their children. The only practical way for a parent to do so if everything uses global/e2e DNS privacy is to give children “managed” devices with non-administrator accounts, or physically hovering over their shoulder all the time (yes children can earn more privacy as they build more trust and mature, but that’s for a parent to decide). It’s much easier and more effective to manage this at a network level.
Furthermore, a consenting adult, without needing justification but common ones include: security, & ad-block, may choose to sacrifice a small amount of privacy (either because they don’t care or because they trust someone with the information) to enter into a relationship where they delegate filtering and monitoring to a third party. If someone wants to build a DNS resolver that doesn't resolve queries to companies run by assholes, then so be it.
Browser mandated DNS privacy prevents all of this (unless you have administrative access to install and configure DNS resolvers on all the devices you own—but you don’t: thanks Apple and the cloud-based internet of shit). And even then if vendors pin keys or certs then have fun. Mozilla certainly isn’t the devil and doesn’t deserve this assessment, but the controversy surrounding fast-tracking proliferation of vendor-controlled DNS “privacy” is warranted.
There’s a final point that often gets overlooked. If Mozilla or Google start shipping browsers that use their own DNS privacy resolvers, it’s a power play (whether intentional or not). They now control DNS, not you, not independent third parties. They now have more data about you. And they can start deploying nefarious things that only work in their vertically integrated web.
I don’t think it’s that much of a stretch to say blindly and hastily pushing DNS privacy without standards in place to defend interoperability of software and internet systems and prevent even deeper vertical integration is bad for the internet.
I am happy we have started exploring ways to extend privacy to the DNS. But I should be able to manage my network in my own home in whatever way I see fit. I do not wish to concede control of such a fundamental system so hastily to browser vendors, of all people.
You say:
> society needs a practical way to for parents to monitor and potentially filter what type of content their children are encountering online.
I agree with you on this point. But how does Mozilla's initiative prevent parents from filtering what type of content their children are allowed to be exposed to online or asserting control over this activity?
I would first argue that this is more than anything a responsibility of the parent - unsupervised internet browsing by children should not really be happening and no technology can save people (children included) from themselves/mistakes/curiosity/etc. as efficient as education can. If the children are too young they won't care that their browsing is filtered, if they are old enough to be knowledgeable about this kind of stuff they will likely find a way to circumvent filtering.
Second, surely, Mozilla can make the DoH functionality optional and, together with other local access & filtering measures, you can probably put in place a system that works for this case. You're again correct that it’s easier to manage this at a network level, but private DNS doesn't automatically impede us to do so, albeit it forces our hands to do so differently if the user can't decide for himself when to use it.
Third, if enough demand will appear for such a feature (i.e. to allow parents to filter browsing for children), I am confident that paid or even free solutions will emerge to address it. The way I see it, users should not concede control to browser vendors, especially if they are Google, but also if they are governments. I argue that we should trust our (democratic)governments with many things, but not with the guarantee that they will always work in the public interest. We need mechanisms to ensure they're always kept in check _before_ things go south.
> If Mozilla or Google start shipping browsers that use their own DNS privacy resolvers, it’s a power play.
That's quite true and a reasonable point that I think needs addressing in a meaningful way. What we should have is more user control.
They should pass out top hats and stick-on curly waxed mustaches to all Mozilla employees, to celebrate.