I’m good with the Apple’s privacy-oriented stance. But I can’t stop to think what will happen when advertisers knock on Apple’s door trying to get their hands on the users’ data that one else can access. Is Apple going to sell it out for more profits?
It's just marketing. Apple has already shown they will sell you out with PRISM.
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.
I think there's a big difference between selling data for profit and the government literally forcing you to give up data based on national security laws or else forcing you to close your business. There's almost nothing Apple can do about the latter case (or any other company for that matter).
Also how would we know if Apple is working with other companies? It's not like they are known to be transparent or Truthful.
Apple puts privacy and security front and center as part of their brand. They zig while everyone else is zaging, trying to make a buck on user data, which they don't do.
One thing I like to remind people of is the fact that the Snowden docs that revealed PRISM were years old at the time of Snowden gathering them, and even older at release... just imagine how much further things have progressed in the 10+ years since. (iirc lots of them had 2007 dates on them)
Opened this post expecting to be hating on another power grab dressed up as protocol engineering, but this one seems to actively /reduce/ the centralization of user data collection in DoH. Props to Cloudflare, I'm impressed.
I still have doubts, 1.1.1.1 was a clear power grab and effort to control more of the internet. DoH in partnership with Mozilla was an extension of that
So I am still suspect of their motives but maybe the negative PR got to be too much
I would like someone to correct me if I am wrong, but I think we can never have 100% privacy because the destination IPs cannot be encrypted or hidden, so as long as the destination IP can be observed, the server that you are connecting at can be obtained (I know a server can host many web pages, but this requires the port, which cannot be encrypted either).
So I don't know to what extent this protocol can be useful.
I'm more worried about persistent, authenticated/ID-linked TCP connections (e.g. APNS) providing the client IP over time to an application service provider (e.g. Apple, Slack, Google, Microsoft, et c), that is, city-level geolocation track history via geoip, than I am the ISP or carrier snooping on what websites I connect to.
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 is "fixed" in DoH the same way it's "fixed" for encrypted SNI: by having a small number of superproviders servicing millions of domains.
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.
> but I think we can never have 100% privacy because the destination IPs cannot be encrypted or hidden
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.
I think there's still pretty good worth in this protocol. DNS is one of the key areas where we voluntarily give away information on every single website we're connecting to to a third party. This protocol certainly helps that--as long as the proxy and recursive resolver do not collude, neither will be able to associate the websites you're looking up with your IP.
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.
yes you CAN if you wish of course. on the other hand nowadays 95% of domains on the Internet can be identified by IP[1][2]. so ISPs still have a pretty good guess what sites do you visit even without DNS or SNI data.
Do you want Google and your ISPs to see everything? Cloudflare and maybe Apple (not sure what infrastructure they’d have in this if any)? Another company like Cloudflare?
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.
The proxy sees the client IP, but can't look at the encrypted DNS request.
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?
While individual clients may not be easily identifiable, there's still a measure of identification that could be made, if you were to configure the public key DNS server to send a different (but persistent) public key to each IP address which asks for the DNS record. (Probably an ISP's caching nameserver.)
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.
They run both, or buy data from the company that runs the other half?
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)?
"""A key component of ODoH working properly is ensuring that the proxy and the DNS resolver never “collude,” in that the two are never controlled by the same entity, otherwise the “separation of knowledge is broken"""
Essentially this is no better than using an HTTP proxy or a VPN.
The user's IP address is masqueraded by the proxy, and neither the DNS mothership (Cloudflare) nor the ISP get to see both who the user is and what they requested. It's an extremely desirable property DoH currently lacks
Tor is not a run of the mill SOCKS proxy, not least in that it inserts arbitrarily high latency into the user data path. On the other hand, an actual run of the mill SOCKS proxy would have visibility of the user's queries and their identity, defeating the purpose of the design.
> an actual run of the mill SOCKS proxy would have visibility of the user's queries and their identity, defeating the purpose of the design.
Why would it have visibility of the queries? If I send a TLS connection (containing my DoH query) through that SOCKS proxy, then the SOCKS proxy is unable to decrypt that TLS connection without breaking certificate verification and thus can't read my DoH query.
> 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.
DNSCrypt needs meaningful industry support otherwise it's sadly irrelevant. I think by now we can all agree "industry support" basically means the 3 browser vendors. DoH has at least Mozilla and Google on board, and presumably Microsoft are tailing along.
>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.
Also, macOS will not let you enable a DoH profile and Little Snitch (or probably any other tool using the Network Extension framework) at the same time. I don't know if this is a bug or intended behavior, but it's a disappointment.
Anyone have any idea why they chose to require 'configuration profiles' here?
There are several tools that can push configuration profiles to many macOS or iOS devices in one go [1]. It's also the kind of thing you don't want users in managed environments messing with if they don't know what they're doing.
Also, don't 'configuration profiles' require that your Mac have an associated AppleID?
I can't see why they'd be connected; being able to configure network settings isn't a "feature" related to having an Apple ID.
Privacy is a buzzword to boost sales even more. Perhaps the biggest problem with Apple is its nasty monopoly strategies, remember the times you could easily add more RAM, change batteries?
Preventing the target resolver from seeing client's IP address breaks GeoDNS. This is already a problem with 1.1.1.1 which doesn't honour the EDNS client subnet extension.
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?
> If the proxy and the target are in the same metro as the user, it shouldn't really matter.
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.
As I see this, this is a very clever move by Cloudflare.
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).
That's a weird take. (a) this is a proposed standard not just some Cloudflare service and (b) you can just use Cloudflare DNS if you want and forget about the rest.
Encrypted DNS only solves hi-jacking, it doesn't provide privacy. DNS must be public. It is trivial to run a DNS server to build a simple reverse lookup table. This is as much privacy as the TSA provides airline security.
> I don't see what kind of snooping these privacy measures are there to prevent.
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.
GeoDNS was always a "works most of the time" hack relying on some widespread (but not universal) implementation details in routing and DNS infrastructure, no?
> 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.
> 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.
Oh, gross! I missed that; I read the TechCrunch article and thought I understand what they were going for. Thanks for the correction. That's disgusting.
> Sullivan said a few partner organizations are already running proxies, allowing for early adopters to begin using the technology through Cloudflare’s existing 1.1.1.1 DNS resolver.
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.
Oh, please. ODoH is a proposed standard. Use whatever the hell proxy/resolver you feel like, wherever you like.
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.
Would have been a million times better if cloudflare had used it's considerable clout and resources to push/lobby for widescale DoT adoption rather than this fucking Frankenstein shit show that is DoH (now with even more garbage attached to it in the form of a proxy)
So I do wonder how such systems can be designed or implemented such that geoip systems can still work.
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.
Sounds promising. Get back to me when it’s gotten to the RFC stage. A ready-made solution thrown over the wall like this, is rarely what is ultimately adopted.
Why not DoT? And DoH is mum on http cookies: "Determining whether or not a DoH implementation requires HTTP cookie support is particularly important because HTTP cookies are the primary state tracking mechanism in HTTP." https://tools.ietf.org/html/rfc8484
Misleading title. Apple devices are not anywhere near ready to utilize this dns protocol. Apart from that, yeah let's shift our dns trust to one of the biggest data resolvers! The irony...
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.
Apple devices are not anywhere near ready to utilize this dns protocol.
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.
I don't think you understand how DNS works.
I don't think you're in a position to comment on what I do or don't know about 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.
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.
Again you keep referring to DoT and DoH which I insist do not encrypt your dns queries from your ISP. They may offer added security but do not keep your requests private. ODoH attempts to keep your requests private from the resolver only. A benefit which is a good step but doesn't ultimately keep your dns private from your ISP.
This is the major flaw I find with such claims of encrypted dns. Your isp can still see which sites you visit, oDoH or not.
So if your DNS request is encrypted to the resolver, and from the resolver to a second resolver (first resolver is ODOH proxy), then is unencrypted from that resolver to the authoritative nameserver, where does the ISP get to see your DNS query? Unless you mean SNI, which is its own thing being worked on[0] (yes, it only works for big CDNs to look benign and you probably could still correlate IPs via traffic patterns. Doesn't mean it'll be as easy as it is now, though).
Until we get rid of SNI[1] in HTTPS for good there will still be providers (like my ISP) that do deep packet inspection on SNI and kill the connection right away if you happen to visit a forbidden site (and this was western Europe, yesterday, on a site behind CloudFlare)
I wanted to link CF efforts on this also but somehow I forgot. Thanks for sharing and I really hope you are successful at this because what I experienced yesterday was really infuriating. Even if having everything behind a CDN to avoid ISP spying is still not the optimal solution, but at least is an improvement given what ISPs have already shown.
I can't find any source on intra working to prevent SNI sniffing. The page itself only mentions DNS, and Googling doesn't reveal any other source for that.
E: NVM, found it. It does like it uses split hellos.
Thanks for the link, just tried Green Tunnel on the use case where my ISP is blocking me and just managed to change the error from PT_CONNECT_RESET_ERROR to PR_END_OF_FILE_ERROR.
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
Enabling proxy manually makes it work but yet, it doesn't circumvent my ISP filtering :(
Part of the counter-argument that has been so prevalent on HN (most recently: [0]) is that when you prevent middlemen on your network from being able to see what website you're browsing, you're doing exactly that: preventing anyone, even a trusted network administrator, from being able to inspect traffic. I'm all for DoH and ECH since US ISPs have a history of inspecting and logging traffic, but it seems like there should be a way to manage the devices on your network besides being forced to set up MDM on everything.
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.
> a way to manage the devices on your network besides being forced to set up MDM on everything.
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.
> it seems like there should be a way to manage the devices on your network
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.
The vast majority of users do not have a "trusted network administrator"; they have a hostile upstream network. That's where the defaults come from. Trusting the network (or anything outside of the device itself) should always be a non-default setting, and nothing from the network should be able to change that setting. You should have the option of configuring a device you own and control to make its traffic inspectable, but that should never be the default.
Do you have a citation for only 10% of internet traffic using CDNs? Even things like cloud load-balances and ephemeral IPs make those associations hard and we’re in third decade of major web properties using CDNs.
The correct answer will be reverse, get rid of SNI completely and enforce ESNI everywhere.
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.
We don't need to kill regular SNI to fix that problem. If a site's DNS record indicates that it supports eSNI, and a connection with eSNI fails, then the browser should hard-fail. And middleboxes can't lie about whether a site supports eSNI, since that's protected by DNSSEC (and it should be coming over DoH anyway). This would break the bad actors without breaking every site that didn't upgrade to eSNI.
As long as plain SNI is still a option, bad actor will try to enforce you to use that. So they can do bad things.
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.
I'm wondering how they still get good performance with a proxy server in between, the plots seem quite close to each other (maybe because logarithmic?).
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.
You, the proxy, and the DNS service, can be in 3 different countries. It's not bullet proof but makes it quite hard for a single government. Unless you are a Bond villain I think this is more than you need.
While I agree that it's a step forward you should proxy your whole traffic anyways if you want to enjoy the benefits of encrypted DNS. Otherwise intermediaries routing your packets can still see what you connect to by looking at the IP header (or SNI, if not encrypted).
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).
This is a neat design, but, does this not just shift the issue of trust as to whether the proxy and the target are colluding:
> 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.
Well, this could probably encourage the creation of privacy-oriented proxys (they just have to forward queries, so it should be relatively inexpensive compared to a full DNS server). What is the likehood of someone getting logs from Cloudflare (who promises it does not keep logs, but let's assume it does) and at the same time hacks into some random privay-oriented organization?
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.
Exactly what I was thinking. It doesn't even really help to run your own proxy on a server somewhere, because although the target wouldn't know for sure what the client's IP address is, queries from just one IP are likely to be easily correlated (statistically or otherwise).
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.
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 suspect that practical matters will interfere with widespread adoption of encrypted DNS.
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.
After seeing similar things throughout the years, I feel like that is very doubtful. When tested, the push for privacy is much stronger than the push for cost.
I’d just get Starlink. Even if the deal was worse in terms of cost it would be a way to say fuck you to the ISP. Without some way to do that ISPs will not be able to get away with such customer hostile behavior.
A cable company offers to wire the neighborhood saving the builder some money. In exchange the HOA setup by the builder bans satellite dishes. In more annoying cases the HOA negotiates a group plan included in your HOA assessment bill; that really stifles competition because paying for an alternative on top of cable is irrational. The FCC banned satellite dish bans back in the 90s.
Apartment building operators still do this scam. The incumbent cable company will share revenue in exchange for the landlord refusing any competitor wiring.
Rent seeking in ISP markets is peanuts compared with zoning though. If real estate was much less supply constrained landlords would never fathom annoying a customer with inferior utilities.
I understand why Cloudflare wants this (marketing, as well as being able to serve their customer’s content through restrictions, thus making them more valuable to those customers),
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?
It is part of their marketing. The fact that others sell or actively use your data, e.g. google, facebook, microsoft, apple was handed the opportunity to charge a premium for the absence of such tracking and data usage. If you watch the presentations, they branded/poised themselves as the privacy centric approach.
As a preface, I am about to describe something I personally view as absolutely horrific. Please, dear reader, in no way interpret these comments as approving.
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.
The bypassing has nothing to do with wanting to hide it from users Even if they did care about hiding it, they know how trivial it would be to discover it, as we already saw only hours after the release.
And those lookups have nothing to do with DNS, so this wouldn’t help nor hurt anything related to that.
The bypassing has to do with exerting their control despite user wishes. Hiding “complexity” from users is one method that is at the core of Apple’s brand.
Yes, very smart people uncover this kind of thing regularly, but the trend feels like Apple is just trying to refine the process until they have a “perfectly secure” device by virtue of the fact that not even legitimate owners are able to enforce their wishes when those wishes are counter to Apple’s mandates.
You’re making assumptions about their motivations, and they’re not correct. They are not doing it despite user wishes. They did it under the reasonable assumption that the user has no such wish. It likely didn’t cross their mind.
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.
Because it's none of Comcast's business what software I run?
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.
For most of the software on my computer, the developer certificate is enough information to know what software I'm running.
All your ISP can see is certificate hashes, OCSP lookups and DNS queries. It can't know what certificate hash is connected to what developer application…
It's not hard to match up a certificate hash to the issuer, because most issuers will likely only have a couple of certificates to simplify internal PKI. It's something that can be solved with a rainbow table, there aren't even salts involved.
It's not hard to match up a certificate hash to the issuer, because most issuers will likely only have a couple of certificates to simplify internal PKI.
These are Apple certificates; they have nothing to do with a company's internal PKI.
It's something that can be solved with a rainbow table, there aren't even salts involved.
2. The OCSP check get cached; the certificate lookup doesn't happen every time you launch an app.
3. You can block the OCSP lookup if you're all bent out of shape about it or strip the developer's signature and sign it using a different certificate.
4. The new protocol for checking will be encrypted and there will be UI for opting out of these checks.
Presumably that's an unsalted hash so that it can be checked against the list of certificate revocations, so whether it's a hash or not doesn't do anything for privacy. It's the same hash of Slack's dev certificate that every other Slack customer is sending.
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.
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
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.
366 comments
[ 683 ms ] story [ 5911 ms ] threadSee also: https://news.ycombinator.com/item?id=25344220
https://guce.advertising.com/collectIdentifiers?sessionId=3_...
Which is blocked at the DNS level on my network.
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.
Apple puts privacy and security front and center as part of their brand. They zig while everyone else is zaging, trying to make a buck on user data, which they don't do.
For starters, here's their transparency report: https://www.apple.com/legal/transparency/
https://www.theverge.com/2020/9/3/21420176/apple-ios-14-trac...
https://www.telegraph.co.uk/technology/2020/12/08/advertiser...
What data can apple give them?
So I am still suspect of their motives but maybe the negative PR got to be too much
So I don't know to what extent this protocol can be useful.
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.
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)
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.
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.
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...
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.
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)?
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.
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?
Why would it have visibility of the queries? If I send a TLS connection (containing my DoH query) through that SOCKS proxy, then the SOCKS proxy is unable to decrypt that TLS connection without breaking certificate verification and thus can't read my DoH query.
> 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.
[1]: https://imazing.com/profile-editor
Also, don't 'configuration profiles' require that your Mac have an associated AppleID?
There are several tools that can push configuration profiles to many macOS or iOS devices in one go [1]. It's also the kind of thing you don't want users in managed environments messing with if they don't know what they're doing.
Also, don't 'configuration profiles' require that your Mac have an associated AppleID?
I can't see why they'd be connected; being able to configure network settings isn't a "feature" related to having an Apple ID.
[1]: https://support.apple.com/guide/deployment-reference-macos/w...
There are soooooo many examples.
You want iphone security? Google iphone security. Hit news.
You want Apple privacy? Google, Apple privacy. Hit news.
This isn't obscure at all. It's a weekly event.
https://nibblestew.blogspot.com/2020/04/your-statement-is-10...
Centralization and too much power in certain amount of hands are the source of all evil.
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.
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).
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.
background: https://news.ycombinator.com/item?id=19828702
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.
> 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.
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.
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.
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.
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.
This is the major flaw I find with such claims of encrypted dns. Your isp can still see which sites you visit, oDoH or not.
0: https://blog.cloudflare.com/encrypted-client-hello/
[1] https://en.m.wikipedia.org/wiki/Server_Name_Indication
[0] https://twitter.com/vinifortuna/status/1304189371688660992
[1] https://news.ycombinator.com/item?id=22654737
[2] https://getintra.org/
E: NVM, found it. It does like it uses split hellos.
Side note, looks like that if installed by snap on Ubuntu 20.10 it cannot automagically change the proxy configuration in Gnome
Enabling proxy manually makes it work but yet, it doesn't circumvent my ISP filtering :(0: https://news.ycombinator.com/item?id=25314182
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.
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.
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.
The server IP address can be easily correlated with the domain for 90% of Internet traffic.
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.
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.
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).
> 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.
Faster - but it does not solve the problem.
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.
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.
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?
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.
Apartment building operators still do this scam. The incumbent cable company will share revenue in exchange for the landlord refusing any competitor wiring.
Rent seeking in ISP markets is peanuts compared with zoning though. If real estate was much less supply constrained landlords would never fathom annoying a customer with inferior utilities.
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?
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.
Yes, very smart people uncover this kind of thing regularly, but the trend feels like Apple is just trying to refine the process until they have a “perfectly secure” device by virtue of the fact that not even legitimate owners are able to enforce their wishes when those wishes are counter to Apple’s mandates.
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.
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...
Are they going to think I'm running some other piece of software signed by Slack Inc.?
All your ISP can see is certificate hashes, OCSP lookups and DNS queries. It can't know what certificate hash is connected to what developer application…
These are Apple certificates; they have nothing to do with a company's internal PKI.
It's something that can be solved with a rainbow table, there aren't even salts involved.
1. Certificates change; probably yearly, knowing Apple.
2. The OCSP check get cached; the certificate lookup doesn't happen every time you launch an app.
3. You can block the OCSP lookup if you're all bent out of shape about it or strip the developer's signature and sign it using a different certificate.
4. The new protocol for checking will be encrypted and there will be UI for opting out of these checks.
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.
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.