Big no on Big Sur: Mullvad disallows Apple apps to bypass firewall
mullvad.net
mullvad.net
It hadn't been clear from previous reports that they all have to do with content-level filtering and VPN's. In that context, it seems to make more sense for Apple to exempt its own critical services (like malware detection and security updates). Kind of the same way applications can't overwrite system files either.
I am curious though: can anyone think of any real-world scenario where it's a genuine problem that Apple traffic isn't routed through the VPN?
When I think of normal uses for VPN's -- security for online work and communications, evading censorship, bypassing geo blocks -- these would all seem to be entirely unaffected.
Is there anything at all an ISP or attacker could snoop on outside your VPN that could ever be genuinely threatening or privacy-invading? Or is there a worry that we don't have a definitive answer to this because nobody's catalogued everything Apple sends and looked for privacy vulnerabilities?
I’m sure there are places that would try to charge Mac users more (or make them more likely to be mugged or something) as they are more well-off statistically.
Verizon used to add http headers identifying their users to advertisers.
Everyone is out to tag you, and it’s because on average it makes them ever-so-slightly more profitable - at your expense, on average.
[2] https://www.cnet.com/news/mac-users-pay-more-than-pc-users-s...
That's amusing, I didn't know about it before. Looks like the story broke 10 years ago:
https://hothardware.com/news/at-capital-one-different-browse...
https://consumerist.com/2010/11/01/capital-one-made-me-diffe...
> Capital One used to offer different mortgage rates to IE users and Firefox users;
This was driven by looking at the User-Agent header your browser sends on every request, not sniffing your local network connection.
Similarly, the Verizon super-cookie header wouldn't affect HTTPS traffic (this was one of the motivations behind HTTPS-everywhere campaigns since even many people who think the NSA can track them no matter what mind marketers doing it) and the point was tracking individual people across multiple devices, not simply gross device fingerprinting. Even if your VPN connection has 100% uptime they can do the traffic analysis I mentioned but since it's almost certain that there will be some non-VPN requests they would already know that you have at least one Apple device.
The underlying issue here is that the kinds of things you're worried about happen in the browser. Using a VPN adds reliability and performance issues but it doesn't prevent this kind of basic identification and very, very few people aren't going to leave some kind of far more identifying cross-site activity which would uniquely identify them rather than just narrowing it down to one of the most popular consumer brands.
The older user-agent / supercookie tags don't work for intermediaries on https, indeed. Which is all the reason why your other metadata (such as contacting apple servers) helps tag you.
> The underlying issue here is that the kinds of things you're worried about happen in the browser.
The things I'm worried about are those I'm yet unaware of. Those things I am aware of (in the browser, for example), I mitigate with browser addons and other tools. But I"m not aware of everything.
I'm not paranoid, everyone IS trying to tag me (and you, and everyone else) for their profit. I am not familiar with ALL the ways they do it, therefore I worry about all information leaks.
That's not a threat model:
https://en.wikipedia.org/wiki/Threat_model
My point is that you need to think about what you're trying to protect against so you can avoid spending time on things which don't matter. For example, if you're concerned that your ISP is going to tell people your IP address and say you own a Mac, you might want to think about whether having a VPN installed would prevent them from doing so, which will not be the case unless you set it up at the router level, configure it to drop traffic if the VPN connection fails, spread your traffic across multiple providers to make things like download profiling harder, etc.
Trying to conceal such general signals from a network-level attacker is a very hard game but once you stop to think about why you care, it becomes clear that it's a waste of time. The two stories from a decade ago were about businesses presenting different rates based on the user-agent. If you're not masking that, you're giving away more detailed information to every site you visit. If you are masking that, you might say that the problem is your ISP selling your IP association to third-parties as part of a “can pay more” list and that clarifies that the real concern isn't what your ISP can see — they do, after, all have your address, billing information, logs from your access to their services, and probably a credit score — but whether they resell it.
Putting it all together, your threat is “third-parties can obtain information which they would not otherwise have about me from my ISP”. That tells you that you need to think about breaking ways they'd make that link: using a VPN for web browsing can make a difference there since it means that Shady Bank™ can't use an IP lookup (assuming your VPN provider wasn't the threat you really needed to worry about) but trying to force Apple system services through it is just wasting time to make things slower and less reliable, and you're much better off spending your time making sure that you use unique contact info, browser containers, etc. to limit the ability of third parties to link your data. In a world where most people use cell phones, Google, Facebook, etc. it's just not that valuable to have a signal which says “IP x uses products from one of the most popular consumer electronics companies”.
A MacOS update with a bug that accidentally leaks user personal info in plaintext.
Use of a Mac in a public, open hotspot setting.
Two that come to mind.
And the second, “Use of a Mac in a public, open hotspot setting” is really the same thing as your first, because if all traffic is encrypted, then being on a public hotspot isn’t leaking your data.
Yeah, actually it makes me feel like the complaints I was reading previously were inaccurate or at least overstated. If I understand the facts right, macOS has both a traditional firewall (like Linux does) and also a system-wide content blocking API (which Linux does not). If you make changes to the firewall, anything you block will be blocked, including requests from trusted Apple applications. Certain system applications bypass the content blocking API.
Honestly this seems entirely reasonable, in fact. They seem like two different tools for two different purposes. And given that most other operating systems don't have built in content-blocking APIs at all, as far as I know, I think the framing of Apple's decision as some kind of power grab is deeply misleading.
Let me know if I'm misunderstanding the substance of the Mullvad post.
I want to agree with your optimistic view of this, but I can't, because I don't think reason was used in making the decision.
I think the reality is probably closer to this:
Product: "so we can't let users block our own apps. it might break things in weird ways and also they implicitly trust us already because we make their OS".
Engineers on the application firewall team: "ok cool, we'll disable users from blocking Apple apps".
Any freedom you're enjoying with PF isn't there because Apple decided it was a good idea. It's there because Apple decided to build on BSD.
I'm actually surprised MacOS even has PF (apparently since 2015, enhanced from other BSD implementations). I did a minimal amount of searching and found this now-relevant gem: https://manjusri.ucsc.edu/2015/03/10/PF-on-Mac-OS-X/
> If two firewalls, Application Firewall & PF, are both running, you may wonder whose rules take precedence. Let’s find out.
> ...
> So one can conclude that PF rules are applied first, then the rules for Application Firewall.
It’s there because Apple decided it was a good idea. If they didn’t think it was a good idea, they wouldn’t have included it. Your next sentence even implies this when it admits that Apple’s inclusion of PF is only a few years old.
> I'm actually surprised MacOS even has PF (apparently since 2015, enhanced from other BSD implementations).
Especially now that it's been publicly documented that it can block Apple apps.
Technically, isn't that what apparmor does?
"Privacy" in the case of the traffic relies on two things: (a) trust in Apple to not get hacked or intentionally share the data with anyone and (b) trust in TLS (not all VPNs use TLS). Apple customers have little control over how Apple operates nor the development/maintenance of TLS. Apple customers can control physical access to their computer but Apple gets a free pass to access/monitor these computers remotely.
What would be a hypothetical "real-world scenario" where it's a genuine problem that Apple traffic isn't routed through the VPN
There is an existing flaw in TLS and Apple does not learn about it immediately, or, some individual/organisation gets access to Apple's private key with or without Apple's consent, a fact which may or may not become public knowledge.
There are a variety of "Apple services" that require TLS-encrytped traffic sent to/from Apple that are initiatied by today's Apple computers, with or without user interaction. Some of the content sent to Apple computers as part of these "services" could come from "fourth party" servers that are part of CDNs who Apple has employed to serve content. To the extent any of this Apple traffic is routed based on geolocation, e.g., from the nearest CDN server, that could reveal something about the user's location.
https://www.richard-purves.com/2016/09/10/apple-services/
The content of this traffic could vary based on the service. Decrypting iTunes/AppStore traffic might reveal the user's AppStore searches and the apps she has installed that have updates available. A full analysis of all the possible data leaks across all the services would be no small amount of work. One more service that the blog post above seems to omit is Apple's NTP service at time.apple.com (Apple performs DNS-based routing). This NTP traffic could produce vast logs of Apple customer IP addresses over time. Some years ago it was said that Shodan.io was using NTP to gather IPv6 addresses to scan by participating in pool.ntp.org.
Decrypting Apple so-called "Push" connections might possibly be viewed with a jailbroken device. Data included in the protocol messages might include connection type, OS version, OS build, device model, etc.
However, I think worrying about the security of TLS is applicable to everything -- it's nothing special to Apple not utilizing the VPN.
It's just as likely that your VPN itself could suffer the exact same problem, or your browser.
And that the mitigation techniques would be the same: reasonably timely security updates.
So it doesn't really seem like there's any higher security risk here? Just the same risk we already accept with everything?
There is a VPN concept called "split tunneling" where your employer can control what data goes through the VPN via work and what data can actually go directly to and fron a destination from your home network.
Employers very cautiously permit or deny this kind of thing - sometimes allowing videoconferencing to use this with specific domains or ip ranges.
Apple goes around all this. They can identify and correlate who works where, where they live and pierce the veil of privacy that should be afforded employees who have to work for someone else.
Also, if there is a vulerability in apple's stuff, some employers would be vulnerable to attacks through the VPN, even though they didn't permit split tunneling.
Either way, seems like a terribly buggy design.
[1] https://www.reddit.com/r/PrivateInternetAccess/comments/gqkh...
It does both make sense and seem incredibly buggy. It'd have to be a fairly impressive attack vector that hits the keyboard firmware, but if you did, I suppose you'd have access to the raw key stream to exfiltrate... not curious to see if it applied on my Mac Pro (which just has a WASD keyboard - I don't use the Apple Magic Keyboard), or a MBP without touchbar (maybe this is the firmware, not the keyboard per se). I do know it is demonstrably the VPN at issue - I can disable our always-on device VPN and the problem goes away, but alas, no easily accessible source that says "verification of HID firmware" or similar.
I also think to have heard that in some cases broken keyboards can cause your laptop to not work anymore at all because of this but I didn't remember where I heard this, does anyone happen to know the source/correctness of that?
Yes, it is both a security leak and a useful feature: it is useful to find a lost/stolen device as the location will become visible whenever anyone powers it up with access to an internet connection.
How does find myMac work in this case?
So that means you will never use that laptop on a network again?
That's.. entirely good I suppose, but would be news to me.
I've even gotten the "you don't have a keyboard plugged in" error message on my laptop (because the keyboard hasn't been detected after ~30 seconds).
Time to dig in, I guess.
This sentence suggests that there's no way to filter/vpn whitelisted traffic, but this is clearly not the case, as evidenced by this article. Furthermore, it's still possible to block/filter traffic on a whole machine basis by using the Packet Tunnel Provider API.
macOS content filtering in Big Sur is no longer able to intercept apps on the exclusion list shipped by Apple, and is akin to 'iptables --uid 501' or 'iptables --command firefox-bin' (actual syntax may vary).
The content filtering API can see which user/app originated the traffic, as it's running higher up in the stack; the packet filtering API cannot, as it's running lower down in the stack.
Apps such as Little Snitch allow you to filter network traffic per-application, which can't be done with PF; you need CF for that, and CF no longer extends to Apple core system processes in Big Sur.
Mullvad's blocks are done imprecisely with PF (presumably they deny 17.0.0.0/8), which is why their blocks break various functionality such as the Mac App Store or:
> For example, the keyboard sometimes takes longer to wake up from sleep mode. Or, in certain situations, the Mullvad app takes longer to detect that the computer is online.
And while they note that it's possible to punch exceptions into the firewall, those exceptions can't be granted per-use, only per-IP.
I happen to not use app-level filtering these days, only pi-hole and and packet-firewall stuff, so I guess I'll be unaffected if I ever upgrade.
Bypassing app-level filtering, though, that sucks.
Trivially is defined as 'click an OK button in a dialog' as the CF permissions process works in Big Sur today.
Malware could still block anti-malware checksum updates with PF, but that requires sudo/root which is 'less easy' than the one-click CF approval process, and PF blocks break so many things on the system that malware can't get away with it without triggering a call to technical support.
(I personally think that much of the issue here is 'macOS background updates can cause $$$$ cellular data drain over wifi-tethered cellular', and that the absence of Low Bandwidth mode in Control Center is one thing that drives users towards these third-party content filters, when they might otherwise not need a third-party product at all.)
Operating a system in PF deny-all default would cure this, as long as LS carefully curated a list of PF allows.
It's possible there are external constraints preventing more widespread use of PF, like "Is this allowed on Mac App Store?".
A VPN simply gives you access to a local network. A specific use of a VPN is masking your internet traffic as if it came from that local network, but there are many uses besides it.
The distrust seems valid to me, but it unfortunately seems to lead to a bunch of confirmation bias.
Apple computers phone home before waking up the keyboard from sleep? What in the world?
My mac become ABSOLUTELY freeze. Impossible to use. In the middle of a fix that UI must have delivery (a host was down for a customer, good timing!).
So, the fact that the machine become a brick is a part that is not considered much on this discussion.
Look, spy on me, ok(?); but also not allow me to move?
Their problems come when you have bad connections or Apples servers are down/overwhelmed. They don’t fail gracefully then.
As a mobile developer I know there are always at least two or more failure modes with any network request, failures because of network/server failures, or failures because internet is off. My clients constantly think Airplane mode is the bad network test case,and I constantly remind them that no, it’s only one possible error cause.
Interesting!
Now, how I could fix the problem with the SERVER DOWN of my customer: :)
Normalized use of the passive voice is no different than being uncomfortable with making eye contact during a regular conversation. Perhaps the writer accounted for that considering the user base.
It seems to me like ultimately the only use cases that should require bypassing network controls will relate to scenarios where there are architectural constraints imposed by the need to minimize latency - and minimizing latency needs to be possible ... so Whatever needs to happen at the architecture level to ensure minimal latency is going to need to happen -- but hopefully only those things ... -- and hopefully only in ways that are visible and decoupled from content-ful network transactions ...