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?

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.

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.

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.

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.

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.

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?

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.

Centralization and too much power in certain amount of hands are the source of all evil.

See also: https://news.ycombinator.com/item?id=25344220

Also how would we know if Apple is working with other companies? It's not like they are known to be transparent or Truthful.

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.

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.

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.

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.

But we don’t, we just have a default

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.

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.

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.

[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...

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)?

That's what we can do with the Portmaster (https://github.com/safing/portmaster). Check it out!

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.

https://techcommunity.microsoft.com/t5/networking-blog/windo...

Your filtering can still break these devices.

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...

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.

Historically, radicalism in the form of whole-protocol-suite replacements has often seen little in the way of adoption. Whereas incrementalism in the form of tunnels and other protocol amendments has been much more successful.

Unsure of the status of non-government large, well funded groups of people with guns there is though.

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.

And those lookups have nothing to do with DNS, so this wouldn’t help nor hurt anything related to that.

It's just that our starting point here was something like 'what can a software engineer do in an hour or so one evening to get their home DNS traffic going through a Raspberry Pi on the LAN'.

I happened to have, er, exactly this experience recently with my (OpenWRT) router(+...) and with that tooling, I couldn't make it work. I settled for DNAT for v4 & DROP^ for v6 because that's what I could get done that evening and it didn't (and hasn't) seem(ed) to be a problem.

^(as in, anything trying to use a different IP, if it's already destined for my DNS that's fine. The hope being that it falls back on v4 at least, even if not the provided DNS over v6.)

Anyone snooping the connection can figure that out and see that my computer said "Check the revocation status of Slack Inc.," and the same goes for literally every other software company's certificate hash.

I'm glad it's being fixed but it's still bad that it was done this way in the first place.

Apple is surely aware of Little Snitch and other firewalls, and that the markets for that are dependant on a percentage of users who want absolute insight and control in to their network traffic. Similarly, there are journalists and sources who must by nature be very cautious about all network traffic. It would be hard to argue I think that Apple is unaware of both of these groups of users, and if they are aware; it must follow that it crossed their mind.

Whether that crossing their mind means they discarded it or intentionally chose to go against it may be a question that only gets answered in hindsight since Apple says very little publicly.

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.

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.

[1]: https://imazing.com/profile-editor

Also, don't 'configuration profiles' require that your Mac have an associated AppleID?

With DoH, it's easy to not just hardcode the resolver's IP but also the resolver's certificate. How would a proxy be able to intercept that?

That's not what I see at all.

I see people pointing out that DoH hurts privacy and reduces control for end users by providing a convenient turnkey solution for device vendors to bypass filtering at the network level.

I also see it pointed out that DoH could have been specified in a way that facilitated filtering for the local network. Given that it's so obviously possible, the fact that it wasn't speaks volumes.

Note that (IIUC) your ISP can still see which sites you visit because TLS still transmits the FQDN in plaintext (https://security.stackexchange.com/questions/86723). Even if that stopped happening tomorrow, the destination IP would still be visible (not quite as bad but still reveals a huge amount of information). On top of all that, DNSSEC already exists which allows you to verify the authenticity of the query result. As such, the argument in favor of DoH would seem to be limited to preventing your DNS resolver (but not your ISP or VPN!) from tracking which sites you visit. I don't find that to be very compelling in light of the immediate downsides.

Be careful what you wish for

What I think will end up happening, most of the devices will go encrypted route [1]. Most things will run over https, and with encrypted sni, you won't even be able to block domains.

Encryption will be backdoored by governments (and of course other people that will reverse those backdoors or have friends in LEA ).

End result is encryption that people are championing as improving our privacy will make us more exposed and more vulnerable, because other people will have more access to our network, devices and data than we do.

I can and do run linux, so I don't have to worry about my os. But my hardware might phone home on its own. Phones are already lost causes. TV's almost as well.

I do hope you are right and I am wrong, I'd much rater be wrong.

[1] You already have hard time buying non smart TV. A lot of things nowadays expect network connection, and that trend is increasing.

That's not the distinction at all.

It's that you should be able to set up interception on the local network at install time, but all other interception should be blocked. It's extremely possible.

It might be good for the average technophobic end user to trust google instead of their ISP, but it’s not good for me to trust google over my ISP.

The device admin of an iPhone is Apple, the device admin of a non-rooted Android phone is Google, the device admin of a Windows 10 PC is Microsoft and the device admin of a smart TV is likely Samsung. Is that the point you want to make?

All of those companies have incentives to collect user data and are known to push user-hostile changes. They also either have known ties with the NSA or can be coerced via National Security Letters, making even the tired point about "defense against state actors" moot. Do you trust any of them?

If, say, Tencent brought a phone to market in the US that turns out wildly popular but happened to exchange vast amounts of data with servers in China, would you be ok with that?

Most devices today have locked-doen bootloaders, so I don't actually have a choice about the device admin for my device. The position of network admin can be abused, too, but at least there is a possibility I can fill this position myself or can delegate it to someone who I trust.

> Ultimately, your choice with uncooperative devices is "block the device or don't", along with "replace it with a cooperative device".

Right now there are huge market incentives to make devices ever more uncooperative. Unless something changes, the choice for consumers will likely be soon "tolerate an uncooperative device and don't block it - or opt out of technological progress altogether".

> That's fundamentally not possible; any mechanism usable by 'good' network admins can be used by 'bad' network admins.

This argument doesn't get any more coherent no matter how often it's repeated. Somehow the tech industry keeps arguing that the key to any kind of mandatory backdoor will leak with mathematical certainty - while employing that exact same kind of backdoor for their own purposes without any worry - in the form of forced updates and forced telemetry. How exactly can the same technology be a security risk when used by a government but a security best practice when used by a private company?

> We absolutely need full control over our own devices, but many of the people most capable of fighting for that control got complacent about it because a subset of people could hack around it with local network interception stunts.

So then what would be your idea how to gain control?