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.
Of course, you'd have to add in some permanent exceptions once you realize just how much hardware and software implodes as a result of this.
Some expected, like peer-to-peer applications, though those allow you to define an outbound ephemeral port range you can limit them to (except perhaps for some poor implementations in commercial game launchers trying to offload bandwidth costs). So some are fairly easy to define.
Others you'll have to log and see. Like your Google Home hardware..
I got some minis and disabled the mics since they had hardware switches. I hacked around a bit emulate sending them audio programmatically and discovered they use external DNS and therefore couldn't resolve the local network web server hosting the audio clips I wanted to play. So I had to permanent-lease the hostname's IP and give it an IP address.. They were already bypassing local DNS blockers years ago.
Key word is any single intermediary. The announcement even explicitly says "no single entity can see both at the same time".
I wonder what it would be like if there were multiple entities in cooperation, each sharing their component of your request with their partners to recover the entirety. You could cover the entire planet with access to even as few as three or five or so large networks.
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.)
NAT doesn't really have much to do with it, other than you with NAT, you certainly have a device on your network that's capable of being a transparent proxy, whereas without NAT, you could just have a unmanaged switch to share your upstream connection between multiple computers; assuming your provider is enlightened and provides ethernet or an ethernet bridge with nothing else in the way.
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:)
https://techcommunity.microsoft.com/t5/networking-blog/windo...
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.
notwithstanding other technical issues, it’s just bad practice to create the sort of experience MITM creates.
when people are used to seeing compromised https when on the corp network or mitm boxes prompting for auth periodically it basically lowers people’s guard on that stuff and opens the door.
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.
Literally all of the security issues caused by the public cloud network architecture instantly evaporate with IPv6, as well as much of the configuration complexity.
No more private networks with non-routable addresses! Instead you get a public-routable IPv6 block.
No more split-routing issues.
No more "gateways" or "peerings" or "service endpoints".
No more Private DNS Zones that may or may not work across virtual network boundaries.
No more copying DNS records into on-premises Active Directory DNS.
Every VM can get a globally unique address. So can every service, of any type! No more conflicts. No need to carefully "carve up" and "allocate" addresses. Just let the system take care of it...
No more sharing IPs with other customers. Every resource, no matter how tiny can get a dedicated address. Got an S3 bucket with 1KB of files in it? You get your own IP!
Every VM or service sees the real client IP, not the reverse proxy IP.
No need for SNI, ESNI, or even host headers since every web server can have a dedicated IP.
No reverse proxy means that load-balancers can simply set up the TCP handshake and then everything runs directly at wire speed. There is never a need to "scale" a load balancer.
The IPv6 addresses are consistent, globally. The IP address of the cloud VM is the address you register on-premises to SSH to it. No NAT magic involved at any point.
Adding a private link (e.g.: ExpressRoute) doesn't change your address ranges. They're the same, only the routes change. This would be a completely transparent change to your firewall rules of whitelisting setup.
Etc...
PS: The current Azure IPv6 architecture reproduces all of the limitations of their IPv4 architecture. They even NAT the addresses! You literally cannot have any of the above, ever, with Azure using IPv6 as it is now. They even limit the number of IPv6 addresses to further restrict you. If they do fix it, you'll have to redo your entire IPv6 setup. It's insanity.
This problem goes back a lot further than that — even prior to having CDNs in common usage you had plenty of different clients sharing IP space at hosting companies and the really malicious stuff just using compromised computers. It's also not fully covering the threat model here: for example, if you are concerned about privacy there are whole classes of device which you simply cannot allow because blocking one feature simply means that the vendor will run everything through the same endpoints required for the device to work.
> 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.
Perfect is the enemy of the good but you have to also think about the asymmetry here. Trying to hijack DNS is only useful when you control the network but neither the client or server. Trying to stop malware by politely asking them to play nicely is a losing game and the IoT devices many people worry about have entire teams devoted to bypassing you as well (e.g. if any significant number of people tried to block a TV from reporting your viewing activity, the endgame is that viewing history and software updates would both go through samsung.com, not that they'll give up millions of dollars in revenue). That leaves you with cases where you do control the client and thus have less invasive alternatives such as installing an ad blocker or using a different browser.
In every case, once they get the server(s) to connect to you lose all further visibility unless you’re blocking 443 and forcing traffic through an inspection proxy.
> Firefox, for example, sends hostname to SOCKS proxy without resolving it.
So a simple proxy can bypass local restrictions.
-----
I remember doing something similar back in my IT days just to see if it was possible. It was.
Then it won't do anything to DNS over HTTPS traffic that is going over port 443. And it won't be able to distinguish that traffic from any other HTTPS traffic.
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?
Not to mention the user interface for configuring them has never evolved beyond /etc/hosts and the total disaster that is /etc/resolv.conf (on modern linux distros).
The fact that I have to run a separate device such as pi-hole to intercept DNS rather than just point my OS resolver to a blacklist indicates how OS level resolvers have not kept up with the use cases people are asking of them.
And of course, no support for DoH or DoT or even DNSSEC.
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 ...
That's what we can do with the Portmaster (https://github.com/safing/portmaster). Check it out!
(I need to block distraction sites during instruction time - otherwise it’s endless Minecraft videos while in zoom meetings...)
Your filtering can still break these devices.
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)
What I'm suggesting isn't merely setting up the 'default' dns server. What I'm suggesting is 'cnaming' the name servers that apps attempt connecting to, to point elsewhere.
It's the user's machine not the application developer's.
But we don’t, we just have a default
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.
What everyone everywhere can resist, though, is corporate surveillance. That's the aim people should have.
It is perhaps worth considering carefully if exposing most people to surveillance they are not equipped to defend against from lots of entities (such as with typical DNS) is an improvement over something like Oblivious DoH. It might even offer some protection against some totalitarian governments in some cases.
Again, you're completely right. Protecting people from corporate surveillance is very important! I just think it might be worth considering that we don't have a perfect answer at the moment, and some subtlety in how we think about this might be in order.
> 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?
You can't tell how many people are going to be covered by that public key, but you could probably make educated guesses, or combine this with other metadata.
I'm not sure I see the point,tbh. If you want to control dns, why not resolve yourself, with whatever cache you need? And if you trust a company to do that for you - assuming the two companies do log "their half" - you're just a data breach, data broker agreement or an acquisition away from a commercial entity having all the data (again)?
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.
[1] https://blog.powerdns.com/2019/09/25/centralised-doh-is-bad-...
[2] https://blog.apnic.net/2019/08/23/what-can-you-learn-from-an...
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.
Specifically, you must install a properly configured .mobileprofile with HTTPS/TLS in the DNSSettings > DNSProtocol part of the payload (along with DNS server addresses of course). Merely pointing at a DoH/DoT supporting DNS server in the settings GUI won't do it, the OS doesn't do any probing and automatically use it just because it's available. For applications DNS Settings is covered under the Network Extension framework [0].
It's definitely nice Apple now has this built-in, and since they're onboard with Cloudflare/Fastly maybe this new twist will be pretty fast too. But obviously they're going to have to make this more automated for it to really make a widespread difference, ideally it'd simply see if the supplied DNS server (manual or DHCP) could run DoH/DoT and then just use it by default with no interaction required.
----
0: https://developer.apple.com/documentation/networkextension/d...
You can use something like iMazing Profile Editor [1] to create a .mobileprofile (which is just XML) to configure DoH or DoT.
Also, don't 'configuration profiles' require that your Mac have an associated AppleID?
Management of devices without authentication and authorization means anyone can do it. Which is the state of things today (for DNS).
Managing traffic over your network and the devices on your network are very similar tasks that aim to accomplish very similar things. However, they are not equivalent tasks. Relying on traffic management to accomplish device management eventually runs into conflicts. These may stem from unmanaged devices, guest devices, unmanageable devices, or the consequences of the total lack of authentication and authorization.
Ultimately, managing traffic and managing devices are not tasks that replace one another.
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.
China seems already done that and blocked esni. And the sites eventually gave up esni because people complaining they can't connect to it.
A deprecation likes that(ex. browsers nowaday marks every http site as unsafe) ensure it is not available to everyone. So some sort of these attacks never work.
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.
Privacy is a luxury. It's something rich people buy and poor people can't afford to concern themselves with. Apple sells a luxury product, and has no particular stake in invading customer privacy at the moment (iAd was never successful enough to change that). So they add a feature to their status symbol to address the concerns of their customer base and work with a partner company that can actually deploy it.
And those lookups have nothing to do with DNS, so this wouldn’t help nor hurt anything related to that.
There's no way for your ISP to know what software you're running.
Gatekeeper checks if your app is malware (or not) and if its been signed with a valid Apple developer certificate. The OCSP look up goes over in the clear currently, but that's how OCSP works everywhere. Your DNS provider can see the OCSP lookup but that's about it.
Apple is in the process of addressing this; you can read the details of how the current process works at https://eclecticlight.co/2020/11/16/checks-on-executable-cod...
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.
Also how would we know if Apple is working with other companies? It's not like they are known to be transparent or Truthful.
> 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.
DoT and DoH should not be confused for encrypted DNS.
Encrypted dns is still a myth to most users. Major resolvers do not support it since it directly conflicts with with their data collection business.
All forms of Internet communications can be largely encrypted. Dns is the last frontier remaining. It remains so for good reason...
Encrypted dns is still a myth to most users. Major resolvers do not support it since it directly conflicts with with their data collection business.
Except those users using Firefox or Chrome, which come with DNS over HTTPS (DoH) preconfigured. Or those who've been running DoT on their home networks, which I setup quite a while ago now.
From the Wikipedia article on DoH, emphasis mine: "A goal of the method is to increase user privacy and security by preventing eavesdropping and manipulation of DNS data by man-in-the-middle attacks[1] by using the HTTPS protocol to encrypt the data between the DoH client and the DoH-based DNS resolver.
DNS over TLS (DoT) RFC: "This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626."
The lack of DNS encryption isn't what Apple and Cloudflare are addressing; it's that whoever runs the DNS resolver can still see the websites you're visiting and ODoH fixes that.
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...