Enterprises aside, there has been a rise of people using solutions like pi-hole in their home networks to filter out traffic not just for ads, but known malicious domains, and telemetry trackers (which Apple does get filtered by, only calling them out specifically because they have an active interest in not being filtered like this).
Yes I think it's also a problem that ISPs are snooping and selling this information, but I think that is a less severe problem than rampant malware infections and the excessive collection of online usage data in the telemetry systems present in every webapp, OS, mobile, or IoT device. This increases privacy in one place, while making it much harder to actively protect yourself from the more aggressive and invasive sources of data collection.
Surely it's progress for devices to be able to securely access name servers? I can't snoop on the network traffic going over https but somehow I can get a list of all names queried?
To me, DoH seems less about protecting the user from attackers and more about protecting apps and devices from the user.
You've started using a pi-hole, and presumably are getting value from it. These protocols can potentially make it so you can't use that pi-hole at all.
Traffic that is local to a network being unencrypted is not a huge privacy problem. If this protocol was adopted by local resolvers, your pi-hole or network router could use it for any requests it makes while still preserving its ability to filter the traffic. It's basically all win under this scenario.
The problem comes back to applications implementing this in ways that can't be managed taking the option away from end users and administrators. Without the protocols specifying control and fall-back behaviours on networks that don't need or want this, it's more harmful than useful.
SSL/TLS's servername extension puts those names in plaintext just like DNS. The popular browsers all include this extension even when the website does not require it.
As such, one can get a list of names by snooping on HTTPS traffic, instead of DNS traffic:
https://github.com/kontaxis/snidump
ESNI-enabled software and Clouflare's ESNI-enabled CDN is an option, but you have to keep making DNS queries to get a key that changes every hour.
I don’t. Like most people I can control my network.
I have all sorts of crap on my network from Bose and amazon and Nintendo and Apple etc on my IoT vlan.
Without going to a monk style digital life aka RMS, the best bet is to segment them into a secure network and limit what they can communicate with. The DOH Culture and the like takes away my freedoms.
If you own the device(s) (your internet connection, phone or a colo), and it is someone else's network - you want security.
If it's a device (smart tv, media player, iot) that you don't "own" on your network you want control.
At least, I couldn't figure out how to do it with IPv6 (no (need for) NAT) - I ended up dropping them if not destined for my desired DNS instead.
(NAT lets you Translate Addresses, usually to save IPv4 space, but here to redirect to a different DNS. IPv6 fixes the address space problem with more addresses, so the hack is done away with, and everything on the network can 'route itself' to everything else without any translation, as pre-NAT and as always intended.)
So no ability to block ads in TV or malicious domains that IoT deviced connect to or even blocking Windows, macOS telemetry network wide as all DNS requests will be encrypted which they are not as of right now.
The problem is that browsers and other applications are just unwilling to let the user see how their products work or decide anything for themselves--or even just architect their installers to involve dependencies on a shared resolver upgrade--and so we end up in this hell of applications actively hiding their traffic from you.
And like, "great": now we have a new version of DoH and have to wait for everyone to upgrade their apps that upgraded to DoH before? This is ridiculous bullshit... this should be a single app on your device you now upgrade. Hell: Cloudflare even develops that app for a number of platforms! They aren't even the problem... it is everyone who jumps on "embedding" this behavior :/ :/ :/.
(For a more technically-comprehensive rant about this, read my comment from a year ago:)
I agree: this absurd trend will lead to every app essentially including an entire O/S. There are several reason why OSes provide services to applications and one is that the OS manages the user's configuration (e.g. what devices are plugged in, where and how to resolve names, cacheing data, etc).
I also find it rather insane the amount of overhead required to resolve a name when an entire http connection needs to be set up and torn down for the process.
If you don’t own the device then 1) should you be interfering or snooping the traffic at all? 2) if you need to limit threat then subnet clients you don’t own.
For your basic premise to work, it also means that the MITM middleboxes will need to support the DoH protocols and support recording, and filtering those responses.
Additionally, custom roots certificates will only work on devices that you can actually set a custom root certificate for, a great example is IoT devices. Is your TV suddenly talking to a botnet or was that a legitimate update?
We can argue about whether those middleboxes are even sane to deploy (hint: they're not), but what is historically true is that they are known to update slowly to new protocols, if at all and are known to cause compatibility issues for traffic that is inherently expected to be unchanged. They're enough of a problem at the _TCP_ layer that QUIC was explicitly designed that minimal information is available in the protocol headers so middleboxes would have less to mess with.
The only effective measure is to block outbound network access and require use of a proxy, possibly optimized by allowing direct traffic only from clients with functioning endpoint monitoring agents.
Also often perfect security isn’t required. Doors with locks are good, but useless if the burglar just breaks the full length glass window next to it. They still serve a purpose, but don’t need to be an absolute comprehensive solution.
If DNS level blocking ever becomes popular enough, malware authors will change their systems to not use the system's DNS, or to use hard coded DNS over TLS/HTTP servers that they know will serve them the data they want.
Preventing proprietary applications from doing malicious things is a constant cat and mouse game. Pi-hole works well for now, I would argue, because it's not popular enough to put a big enough dent in the success rate of malware.
- Motorola MH7022
- Eero
- Disney Circle
Basically any of them that say "content filtering" in their product sheet are using DNS level filtering.
> ...the trash resolver of their operating system...
I'm very curious why you think the well tested, vetted, and constantly updated resolvers built into OS's are "trash". Is it just because most don't have support for DoH or DoT?
This DNS server gets its upstream resolution from nextdns.io which is configured with several blocklists - including one that is roughly analogous to ublock origin.
On my local network, my DHCP server hands out my DNS server to all clients.
This means that all clients on my network get fairly robust ad-blocking even if they do not have an adblocker installed. It also means that non-browser clients (Sonos, AppleTV, etc.) get ad/tracker blocking as well.
DoH sort of breaks all of this, unfortunately.
Individual devices or clients or browsers can now connect to trackers and ad-servers over HTTPS, bypassing my adblocking resolver.
I thought that perhaps there was a solution wherein you would pre-query every single new IP you connected to over HTTPS and send it a test DNS query .. and if it answered DNS, you would just refuse to talk to it. I think this falls apart, however, if (for instance) google just queries "google.com" ... now you're denying google.com because it answers DNS queries over HTTPS...
Look, back when 8.8.8.8 came online I could just smell it ... I knew there was a user-hostile arms race somewhere in there I just didn't know where. Now we know.
https://blog.apnic.net/2020/02/28/how-to-deploy-dot-and-doh-...
With the Portmaster (https://github.com/safing/portmaster) we actually tackle this problem by notifying software (eg. Firefox) or blocking their connections, forcing them back to plain DNS, which we can redirect and handle. Take a look!
If so, I foresee blocks on DoH/etc to common resolvers like 8.8.8.8 and 1.1.1.1. I'll be blocking them at home on the assumption that I only want regular DNS lookups so I can point them to my own DNS server etc.
There is a cost to firewall rules like that as well. Who is going to maintain a list of all the IPs on the internet that are hosting DoH servers that could be used? What about the potentially more prolific proxies specified in this protocol enhancement? How does a network administrator keep all of those in sync with their edge networks? How does a home user?
Since DoH uses HTTPS there is no reason a service can't be multihomed on the same IP just like SNI allows multiple HTTPS servers on one IP. Would you be willing to block a legitimate website just so the applications on your network might fall-back to the name server you want them too?
I wish it were that easy but it's very predictable that google will start resolving DoH on plain old "google.com".
So will everyone else ... it's not going to be malicious.userhostile.resolver.samsung.com, it's just going to be samsung.com ... so you can block it but you'll be blocking more than just the resolver ...
(I need to block distraction sites during instruction time - otherwise it’s endless Minecraft videos while in zoom meetings...)
The options are simply not there for consistent management of your network.
Instead of setting your devices to use a dns server of your choice it’s ignored by the apps
Some apps allow you to configure them, so now you’re configuring 200 apps on 20 devices rather than just one dhcp setting.
(Oh and OSs have generally broken hosts files)
Never forget the lesson in "Using Metadata to find Paul Revere": https://kieranhealy.org/blog/archives/2013/06/09/using-metad...
> Administering devices with network settings is convenient, but rapidly vanishing because there's no technical difference between you administering your local network and a totalitarian ISP administering their users.
Your ability to terminate things locally means that finding Paul Revere with metadata isn't needed. It's a lot of work when you can just directly look at all your country's traffic.
> However, each of these guarantees relies on one fundamental property — that the proxy and the target servers do not collude. So long as there is no collusion, an attacker succeeds only if both the proxy and target are compromised.
I'm not sure how an end user would be expected to assess this any more than they could ascertain whether any particular DoH/DoT provider is as trustworthy as they claim.
So you convince some neighbors to use your proxy... As the number of clients grows, so does the uncertainty that the person running the proxy isn't colluding with the target, so you're back to the same trust issue that you were trying to solve in the first place.
Of course, one might imagine a State actor using all their resources to do just that. But this would be a very complex attack. At least, it would stop all kind of ad tracking.
The worst part of this proposal is that it will further centralize the DNS infrastructure.
Apple/Cloudflare are working on privacy-friendly protocols that reduce the amount of information exposed to them.
At exactly the same time, Google is working on proxying browser traffic through them without any consents [1].
Thus I am using Google Chrome only for Web Dev
The DNS server sees (deciphers) the DNS query, but not the client IP address.
It's a proxy, but with the sensible data encrypted with the server's public keys to hide it from the proxy. Cloudflare never knows who is sending the requests. How can they get access to the data?
I don’t know the answer but I’m curious to hear everyone’s thoughts. Personally I’d like to prevent Google and my ISPs but Cloudflare could easily become Google in many ways.
So I don't know to what extent this protocol can be useful.
With current encrypted SNI proposal, your privacy (between you and the superprovider) is /improved/ by talking to a site behind a large aggregating provider. It sucks (since the superprovider still sees everything), but that's how it is.
edit: added clarifications in (parens)
Every iPhone connects to APNS for push notifications and stays connected, and, last I looked at the protocol, the client certificate was linked to the device serial number. That's quite a geoip tracklog dataset, and AFAIK you can't turn it off.
It's to the point now that to keep my city-level location private from Apple, I'm not putting SIMs in any of my iPhones/iPads any longer, and carrying a battery powered VPN travel router (with a SIM uplink in it) for them to talk to. Super annoying that it has to come to this.
This problem is solved in I2P (https://geti2p.net) by adding a few intermediate hops between you and destination. You will know someone is connecting to the network, but you can't find what they're doing.
You can host multiple web sites in the same port since the 1990s, using name-based virtual hosts (https://en.wikipedia.org/wiki/Virtual_hosting#Name-based). It's rare nowadays to use a port other than 80 (for http://) or 443 (for https://) for public web sites.
It does have its limitations; a MITM can still just as easily see which IP addresses you connect to and determine which websites are associated with those IPs. But ODoH isn't really meant to fix that. A VPN would be better suited to fix that particular privacy concern.
Essentially this is no better than using an HTTP proxy or a VPN.
In this proposal the DNS-proxy doesn't know what you've sent to the DNS resolver.
So I am still suspect of their motives but maybe the negative PR got to be too much
> The target [resolver] sees only the [DNS] query and the proxy’s IP address. The proxy has no visibility into the DNS messages, with no ability to identify, read, or modify either the query being sent by the client or the answer being returned by the target. Only the intended target [resolver] can read the content of the [DNS] query and produce a [DNS] response.
> The whole process begins with clients that encrypt their query for the target using HPKE. Clients obtain the target’s public key via DNS, where it is bundled into a [SVCB/HTTPS] HTTPS resource record and protected by DNSSEC.
> Clients transmit these encrypted queries to a proxy over an HTTPS connection. Upon receipt, the proxy forwards the query to the designated target. The target then decrypts the query, produces a response by sending the query to a recursive resolver such as 1.1.1.1, and then encrypts the response to the client. The encrypted query from the client contains encapsulated keying material from which targets derive the response encryption symmetric key.
> ...50% of the time ODoH queries are resolved in fewer than 228ms.
BTW, DNSCrypt supports "oblivious" encrypted DNS queries via what it calls Anonymized Relays https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Anonymized-D...
Note that DoH (and DoT) shipped in iOS 14 and Big Sur, though aren't particularly easy to enable.
Management of devices without authentication and authorization means anyone can do it. Which is the state of things today (for DNS).
Administering devices with network settings is convenient, but rapidly vanishing because there's no technical difference between you administering your local network and a totalitarian ISP administering their users.
My ways of dealing with the modern world, in order of preference:
1. Use Free software, so that devices develop user-empowering features instead of being locked down.
2. Firewall all general Internet access from a device/VM, and let it talk to local network devices only.
3. Firewall the device/VM from accessing most of your network, allow Internet access (ideally through a VPN), and inspect the hardware to make sure there aren't microphones or cameras.
It's sort of like cleaning malware off of an infected PC from within the infected OS.
It was always theoretically impossible, and now we're just seeing the gap of "Well in this case the enemy was imperfect" closing. It was never going to stay open in the first place.
[0] https://twitter.com/vinifortuna/status/1304189371688660992
Side note, looks like that if installed by snap on Ubuntu 20.10 it cannot automagically change the proxy configuration in Gnome
green-tunnel:system-proxy [SYSTEM PROXY] error on SetProxy (Error: Command failed: gsettings set org.gnome.system.proxy mode manual
green-tunnel:system-proxy /bin/sh: 1: gsettings: not found
E: NVM, found it. It does like it uses split hellos.
Most bad entity now only need to block ESNI, and then the client will happily fallback to plain SNI.
If everyone enforce ESNI only, then it is not gonna going to work.
Just like nowadays, a browser can't view https site is completely useless because most of sites on internet were already encrypted(and the percentage is only going to be more) no matter how useful/useless the site is.
The server IP address can be easily correlated with the domain for 90% of Internet traffic.
Given generally DNS is just the start of an intereaction, usually followed by the connection directly between the client and intended destination, I don't see what kind of snooping these privacy measures are there to prevent.
> Preventing the target resolver from seeing client's IP address breaks GeoDNS.
If the proxy and the target are in the same metro as the user, it shouldn't really matter.
> This is already a problem with 1.1.1.1 which doesn't honour the EDNS client subnet extension.
1.1.1.1 runs at Cloudflare's edge. Most likely it is recursing DNS from more or less the same location as the user and so ECS isn't really required when in fact it exposes the client unnecessarily to upstream name-servers.
> I don't see what kind of snooping these privacy measures are there to prevent.
The one where DNS resolvers build to sell browsing profile of its users?
Having ran one of the largest public DNS resolvers on the internet, I can tell you it is a big problem. GeoIP providers do not have the fine grained data to be able to tell that a resolvers unicast address is in Seattle vs Chicago for example.
Cloudflare doesn't care about edns-client-subnet because the only downside is that other CDNs appear slower to their users.
The point of this is to prevent some cloudflare competitor offering DoH, but logging what dns names each client looks up, and selling that information, or using it internally.
Think about the ways that facebook would abuse that information if facebook ran a popular DoH resolver. For example, they detect that you have used a hookup app (based on dns lookups for their servers), and boom, now your facebook feed is full off condom adverts. Or thousands of other scenarios, some even more creepy than that.
It's intentional to force websites to move to their CDN or atleast use a CDN with anycast and prevent you from making your own CDN like you could cheaply before (spinning up DO droplets and doing loadbalancing with geo DNS).
background: https://news.ycombinator.com/item?id=19828702
And I for one am happy that they have taken up this cause and put their weight behind it, whatever their intentions may be, the effect is that it makes the web more private for those of us who deem it important to move away from the "monetizing data" cancer that has spread all over the internet.
https://tools.ietf.org/html/draft-pauly-dprive-oblivious-doh...
If not, here is a PaloAlto Networks blog advertising capability to block all DoH traffic, presumably at work [0]. It looks like you might not be able to use DoH at work, the way it currently stands. I wonder what would be the right solution?
[0] https://live.paloaltonetworks.com/t5/blogs/protecting-organi...
You understand correctly. DoH mostly defeats pihole and the like. Presumably Google and other ad companies love this.
DoH will not be extended to allow firewalls to decrypt it. The entire point of DoH is that firewalls cannot do that. It's not hard for an administrator to set up their own DoH server, though, so there is no need as long as that server can be configured at the network level. This is currently possible through group policies on Windows and most MDM applications on mobile devices.
The nice thing about encryption is that only the software and the server know what is being exchanged. The not-so-nice thing about encryption is that only the software and the server know what is being exchanged.
You already can't see the difference between your computer connecting to some S3 bucket to download a picture of a cat or malware connecting to a S3 bucket to get a list of IP addresses mapped to host names. It's possible to run fully-fledged VPNs that look exactly like normal HTTPS traffic on the network level. DoH changes nothing about that.
On enterprise networks, IT administrators can already put measures into place that prevent DoH on support applications and restrict HTTPS connections to trusted hosts (through SNI sniffing + validating the connection). The upcoming encrypted SNI will make this harder, but group policy will be able to disable eSNI on any trusted computers and browsers, leading only untrusted software to be unverifiable, which can then be reasonably classified as malicious.
If IT administrators cannot put measures on employees' devices then... well, they've already lost. Before DoH, they just didn't know that they'd lost yet.
Palo Alto currently blocks DoH by decrypting all TLS traffic (ranging from cookie recipes to naked pictures your phone is syncing to the cloud) with a man-in-the-middle attack which requires their certificate authority to be installed on your system. They filter out the DNS requests inside those TLS streams and apply some kind of rule to them. Right now, they can either block the requests or change the contents (as long as the website and/or client doesn't use DNSSEC).
With ODoH, changing the contents will no longer be practical, but blocking the connection will be. Together with decent group policy settings, networks with such a setup should be as safe as they were without ODoH.
On a side note: these types of middleboxes are often trying to be transparent and silently violate many standards, breaking stuff that works on every normal network. Stuff like these firewalls are the reason that TLS 1.3 is pretending to be a special type of TLS 1.2 every time it connects, because otherwise some big middlebox vendors' platforms freak out and kill the connection. I doubt the inevitable transition towards HTTP/3 or even HTTP/4 will do these boxes much good. I don't put a lot of faith in devices like this.
but why does Apple want this?
My knee-jerk is that they want to further hide/make unstoppable things like the Gatekeeper network checks, but there has to be more right?
Firstly, Apple loves to act like they are always taking your privacy very seriously (of course that's not always true), so for the cost of a few engineers, they get a massive marketing point. "We take your privacy so seriously that we developed a new protocol to do so"
Secondly, Apple has an awful case of NIH syndrome. If they didn't develop it themselves, they would rather develop it from scratch themselves
Not when it comes to security and privacy. They knew DoH and DoT were good, but not good enough when it comes to privacy, which explains why they didn't just implement it like Google and Firefox did.
Instead, the worked with Cloudflare to standardize something that's better.
So while ODoH is a good thing (and also recommended in this study which has shown the weaknesses of DoH/DoT https://www.esat.kuleuven.be/cosic/publications/article-3153...) and is very similar to DNS over Tor with a DNS hidden service resolver (which Cloudflare also provides). It won't prevent a skilled and motivated adversary from determining your activity and possibly apply censorship.
I would guess that a solution to mitigate these would be to use an hybrid solution of VPN over Tor (or Tor over VPN) while also using DNS over Tor or ODoH and eSNI.
If you wanted to go a step further, you can even allow "chaining" of proxies, such that the path a query takes might be, in an extreme example, similar to how Tor operates:
Client -> Proxy 1 -> Proxy 2 -> Proxy 3 -> Target -> Resolver
Anyways, this is kinda sorta interesting, I guess, but honestly I'm more excited by and looking forward to the (hopefully!) eventual adoption and roll-out of "DNS SVCB and HTTPS RRs" [0] -- one of the other I-Ds (linked in the OP) on which ODoH is built -- and I suspect many other HN'ers will be as well (although I'd happily settle for SRV RR support in browsers).
--
[0]: https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-02
Once we say we need encryption on the first hop, then I can see the logic in using a stateless protocol instead of TLS for the second hop, to avoid TLS-in-TLS and all the round trips associated with that.
Side note: It'd be cool if these new protocols used the more generic Noise Protocol Framework [1] instead of a custom, more specialized protocol they just came up with like HPKE [2].
[1] http://noiseprotocol.org/noise.html [2] https://www.ietf.org/id/draft-irtf-cfrg-hpke-06.txt
Also, not sure how useful the Tor comparison is, since Tor does 3 hops as opposed to their 1 so it would be a shame if it doesn't beat that.
Will ISPs be too scared to sue Apple and Cloudflare for this? Or are they giving them an out?
Which wouldn't be the case if everyone loses access to the IP + DNS request info.
The blog post only discusses how the proxying and encryption affect latency but not the processing at the server. In contrast to plain DoH (or DoT), where only symmetric cryptography is used after the first set-up, ODoH requires asymmetric cryptography (which is several orders of magnitude slower) for each individual request. The "less than 1ms" that they claim for the 99th percentile is no problem for the client but it is a problem for the resolver. Asymmetric cryptography is also used for verifying DNSSEC responses, but this is only necessary for records that are not cached.
On the other hand, an ODoH resolver may require to set up and keep track of a lower number of TLS connections as the number of proxies is likely smaller than the number of clients.
In my state, Comcast is going to start charging heavy bandwidth users extra. After a few people get surprise bills, I suspect that lawmakers will require that internet providers break down a bill by application.
I guess it won't take long until the first community or HOA decides to ban Starlink dish installations for faked "optical nuisance" issues.
What does Cloudflare think of Safari's new CNAME-cloaking detection to block cookies? https://webkit.org/blog/11338/cname-cloaking-and-bounce-trac...
The reason I ask is because Cloudflare's "orange cloud" DNS mitigates that protection because it prevents Safari from detecting the cloak. On the other hand, I haven't run into many engineers who think CNAME-cloaking actually hurts privacy in light of Safari's other efforts to partition local storage.
Does Cloudflare think it would be help privacy for Apple to know the final IPs behind orange cloud DNS?
I thought HTTPS proxying (or rather: Any TCP protocol) was a solved problem by the HTTP CONNECT verb or SOCKS proxies.
What am I missing?
> “What ODoH is meant to do is separate the information about who is making the query and what the query is,” said Nick Sullivan, Cloudflare’s head of research.
> In other words, ODoH ensures that only the proxy knows the identity of the internet user and that the DNS resolver only knows the website being requested. Sullivan said that page loading times on ODoH are “practically indistinguishable” from DoH and shouldn’t cause any significant changes to browsing speed.
This is incorrect; the proxy doesn't decrypt. It just proxies. From https://blog.cloudflare.com/oblivious-dns/ :
> The target decrypts queries encrypted by the client, via a proxy. Similarly, the target encrypts responses and returns them to the proxy. [...] The proxy does as a proxy is supposed to do, in that it forwards messages between client and target.
A tor-like solution is the only real solution for this threat model
While I'm sure aws route53 and cloudflare's own routing systems can handle this properly, Cloud isn't quite the answer. Not every workload fits on the cloud (see: Discord, which runs on leased servers), and a system that breaks down if your rented datacenters aren't in alignment with Cloud operating regions doesn't make a great solution.
As far as I'm aware (don't work there), only bandwidth/CPU-heavy stuff like voice and video live on rented dedis; the core chat services live in GCP.
Unfortunately I suppose the only way to really do that is with a resolv file (adlist/blocklist) of DoH hosts (which exist) but instead of pointing to 0.0.0.0, point to <preferred DoH>.
Edit - d'oh! I see it now - that would mean DoH provider knows query and IP, whereas here the ODoH proxy knows your IP but not the query. Nice.
Who is the proxy here, and who the DNS resolver?
> A key component of ODoH is a proxy that is disjoint from the target resolver. Today, we’re launching ODoH with several leading proxy partners, including: PCCW, SURF, and Equinix.
Pretty crucial hyphen
In other words, in order to thwart efforts to make the internet anonymous , US companies are planning to takeover DNS for the vast majority of people.
DNS is a shit show of unencrypted data flying around being scooped up by God-knows-who and along comes someone proposing a standard to fix said shit show and this is the response people get.
What data can apple give them?
https://www.theverge.com/2020/9/3/21420176/apple-ios-14-trac...
https://www.telegraph.co.uk/technology/2020/12/08/advertiser...
Who knows what other backroom deals are happening outside our knowledge. The only reason we found out about PRISM is because the gigantic scale and Snowden sacrificed Everything to let it be known.
> The whole process begins with clients that encrypt their query for the target using HPKE. Clients obtain the target’s public key via DNS, where it is bundled into a HTTPS resource record and protected by DNSSEC. When the TTL for this key expires, clients request a new copy of the key as needed (just as they would for an A/AAAA record when that record’s TTL expires). The usage of a target’s DNSSEC-validated public key guarantees that only the intended target can decrypt the query and encrypt a response (answer).
So this looks like relies on DNSSEC as a core part of its security, and that any resolvers willing to participate in this protocol would have to set up one.
Centralization and too much power in certain amount of hands are the source of all evil.
https://guce.advertising.com/collectIdentifiers?sessionId=3_...
Which is blocked at the DNS level on my network.
You can resolve the websites from the Alexa top 100k list and create a ipaddr -> website map that will successfully apply to 90% of Internet traffic without ambiguity.
A lot of research papers also show how easy it is to fingerprint and detect a TLS handshake.
Assuming the SNI problem is going to be solved, the other problems are still here.
TL;DR: use Tor.
Governments subpoena the information or just block the protocol outright. ( or in China, get it delivered to their door by Apple )
Commercial parties have a bag full of tricks from fingerprinting to embeds on the page itself to track you.
Privacy seeking users are already tunneling their traffic.
That leaves script kiddies at Internet cafes. TLS kind of fixed that already so... Good work?
Exactly that, no more, no less.
If you need more than that use ToR or similar.
DoH/DoT is still useful because it allows you to proxy your DNS over Tor (for example) without having to worry about tampering (or surveillance if you also use separate circuits per domain).
Encrypted dns might be already in use by government or military agencies, but they know too well the effects of cascading this tech down to the masses. They will never let this reach the public.
The latest versions of macOS and iOS already support DoH and DoT; Apple could push an update tomorrow to enable ODoH tomorrow if they wanted to.
Encrypted dns might be already in use by government or military agencies, but they know too well the effects of cascading this tech down to the masses. They will never let this reach the public.
You do know we've had encrypted DNS for years, right? It has some issues, which this new protocol is designed to address. There's no reason to believe "they" can or will intervene to stop ODoH.
But seriously, fuck this protocol and fuck every other BigCorp-sponsored protocol to remake the Internet. We the People Who Implement Protocols are too busy keeping the lights on to chase incremental, nice-to-have improvements.
https://nibblestew.blogspot.com/2020/04/your-statement-is-10...