Big no on Big Sur: Mullvad disallows Apple apps to bypass firewall(mullvad.net)
mullvad.net
Big no on Big Sur: Mullvad disallows Apple apps to bypass firewall
https://mullvad.net/en/blog/2020/11/16/big-no-big-sur-mullvad-disallows-apple-apps-bypass-firewall/
102 comments
> can anyone think of any real-world scenario where it's a genuine problem that Apple traffic isn't routed through the VPN?
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.
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.
A bug that accidentally disables the encryption on the encrypted protocols Apple is using? That seems rather unlikely.
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.
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.
The fact that you use an Apple device is readily apparent from these traffic patterns - that alone seems worth hiding with a VPN.
What's your threat model for this concern? Local networks are still going to see the MAC address (randomization means they can't track you specifically across different WiFi networks, but they still know it's an Apple device). VPNs aren't perfect so an attacker is almost certainly going to see enough from DNS queries, HTTP user agents, TLS SNI headers, etc. to detect the OS in the times where the VPN isn't active. Traffic analysis is also likely to be leaky at this level, too — if you see a big download around the time that Mac/iOS updates come out that's pretty indicative even if you can't see the traffic.
Capital One used to offer different mortgage rates to IE users and Firefox users;
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.
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.
Orbitz used to charge higher fares for Mac users [2]
[2] https://www.cnet.com/news/mac-users-pay-more-than-pc-users-s...
[2] https://www.cnet.com/news/mac-users-pay-more-than-pc-users-s...
> Capital One used to offer different mortgage rates to IE users and Firefox users
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...
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...
None of those are a threat model and if you think about them for a minute you can understand why they aren't relevant.
> 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.
> 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.
They are a threat model for your wallet, which some people consider a threat model.
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.
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.
> They are a threat model for your wallet, which some people consider a threat model.
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”.
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”.
On my home network I used this [1] guide to set up a pihole with dns over https. Should stop snooping of some of those types by anyone but your chosen DNS target at least (middlemen, ISPs etc). Though I can't comment on other types of attacks.
[1] https://docs.pi-hole.net/guides/dns-over-https/
[1] https://docs.pi-hole.net/guides/dns-over-https/
[deleted]
> This makes me feel somewhat better, honestly. The fact that packet-level firewalls work is reassuring.
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.
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.
> Honestly this seems entirely reasonable
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.
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.
> 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.
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).
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).
It's not like PF was billed as a hot new feature of the OS. I believe it's a happy accident that we got PF, and I won't be shocked if it goes away in the future.
Especially now that it's been publicly documented that it can block Apple apps.
Especially now that it's been publicly documented that it can block Apple apps.
The fact that all of this still has had to be deduced ad hoc in some reverse engineering-type paradigm also should give anyone pause. The fact packet filtering works is better than if it didn't but that's almost besides the point. The problem is Apple deliberately obfuscating important security details from the user. It's literally asserting privilege of itself over the user/device owner in an essential way, if not entirely through filtering protocol than through informing about the protocol.
> a system-wide content blocking API (which Linux does not
Technically, isn't that what apparmor does?
Technically, isn't that what apparmor does?
Because Apple users allow Apple to manage so many aspects of the computers they sell, remotely, it seems to me getting access to Apple traffic or the data Apple collects and stores about its customers is nearly as informative as getting physical access to the customer's Apple computer.
"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.
https://github.com/mfrister/pushproxy
"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.
https://github.com/mfrister/pushproxy
Thanks for the explanation.
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?
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?
If you work for someone and had an apple computer to work from home, bypassing the VPN would merge your personal life (ip address, location, so on) with your job. All packets that go direct to apple are identified with your real home ip address.
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.
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.
Since the application attestation service sends application hashes unencrypted, any third party observing the traffic can fingerprint you if you use exotic enough applications.
Do they even have to be exotic applications? I don't use Chrome very often but I think it is installed. That means I have a very current FF but some specific old version of Chrome. Ditto for a bunch of stuff installed by Macports, that all just updates at once but pretty infrequently. I don't recall the last time I updated Steam. Seems easy to fingerprint someone with just a handful of even normal apps.
I find it worrying that the side effects of leaving Mullvad enabled are that the keyboard takes longer to wake from sleep. What the hell is going on here?
My guess is that this is somehow linked to iCloud device handoff, which does all kinds of questionable stuff [0] on e.g. device wake.
[0] https://arxiv.org/pdf/1904.10600.pdf
[0] https://arxiv.org/pdf/1904.10600.pdf
This is also an issue on always-on VPNs, where the process of verifying keyboard firmware can result in the alarming "Please connect a keyboard via Bluetooth" dialog on even a laptop. It goes away as soon as the verification completes, but is not the fault of Mullvad per se.
I'm aware of this being a well-documented issue starting in Catalina [1], but I wasn't aware there was a definitive answer as to why. Do you have a source for the fact that it's firmware verification?
Either way, seems like a terribly buggy design.
[1] https://www.reddit.com/r/PrivateInternetAccess/comments/gqkh...
Either way, seems like a terribly buggy design.
[1] https://www.reddit.com/r/PrivateInternetAccess/comments/gqkh...
I wish I did. I just remember it being a huge annoyance.
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.
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've seen this when using vmware fusion.
I mentioned this issue regarding my laptop during the apple server downtime last week. Someone mentioned that the T2 chip connects to Apple during wake from sleep. I'm guessing the keyboard goes through the T2 chip and until the timeout is hit it won't let it through.
This is comical.
Yes, from what I know the keyboard goes through that chip.
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?
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?
I assume this is related to the iCloud 'Find My Mac' feature: whenever a device wakes up one of the first few things it does is update its location on iCloud.
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.
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.
I've wondered about the practicality of this for some time, but never came up with an answer. For a device with an always on connection like an iDevice with cell chips, the location can always be updated. However, a locked laptop with WiFi only would need to be unlocked to be told to join an available WiFi network. If I'm someone that is inclined to do something with an Apple laptop with a T2 chip that has found its way to me, I'm not going to allow it to join a WiFi.
How does find myMac work in this case?
How does find myMac work in this case?
As of macOS Catalina, it can piggyback off nearby devices. Even if the device is turned off, it still may be able to broadcast location if there are other devices nearby.
> If I'm someone that is inclined to do something with an Apple laptop with a T2 chip that has found its way to me, I'm not going to allow it to join a WiFi.
So that means you will never use that laptop on a network again?
So that means you will never use that laptop on a network again?
Not parent but are you saying wiping it doesn't stop it phoning home to report Find My Mac location for the previous installation?
That's.. entirely good I suppose, but would be news to me.
That's.. entirely good I suppose, but would be news to me.
Its more than that, You can't wipe it at all until you log in with the apple account it was connected to. Rendering a stolen laptop effectively bricked and only useful for parts.
That's not necessarily true. There is a permanent vuln embedded in the T2 chip. If you have a locked laptop, getting past the lock is possible.
Is that new with Big Sur? I wiped and reinstalled at the weekend (preparatory to upgrading) just by holding CMD+r on boot > disk utility > format.
I think its any macbook that has a T2 chip which only came out somewhat recently I think.
Here's the comment in case anyone's interested: https://news.ycombinator.com/item?id=24839101
Saw this earlier, likely related https://news.ycombinator.com/item?id=24839101
This explains a lot, actually. I travel a lot, so I often deal with very bad internet connection quality. I also often have the problem that my keyboard takes a long time to start working again after sleep mode.
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).
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).
Does this mean that MacOS packet filtering does work as expected, and can block any/all traffic, including traffic to Apple? That's good, and what I would hope, but then I'm a little confused about what nastiness Apple is doing in Big Sur related to firewalls.
Time to dig in, I guess.
Time to dig in, I guess.
macOS packet filtering in Big Sur is unchanged, offering src/dst host/port/proto filters, as is typically thought of to be a 'firewall'.
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.
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 wonder if a Little Snitch type application could look at both data flows and correlate the two. Anything that packet filtering detects that isn't also detected by content filtering could itself be handled with custom rules.
It might be able to report that unfiltered traffic occurred, assuming it can detect unfiltered traffic using pcap, but it wouldn't be readily possible to prevent the initial packet from being sent prior to a rule specifically being created to prohibit it.
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?".
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?".
Okay, this makes sense, thanks.
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.
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.
I assume that Apple's reasoning is "Userspace malware shouldn't be able to trivially intercept anti-malware checksum updates".
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.)
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.)
A VPN provides internet connectivity, therefore it is more like a partially broken internet connection instead of a firewall.
Doesn't a VPN work over the internet (in order to access a local network). So I wouldn't say it provides internet connectivity (as you already need to be connected to the internet to connect to a VPN).
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.
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.
This is the best description of a "programmer solution" ever.
The nastiness is based on misunderstanding of what Apple is doing, and of how their API’s work, coupled with a healthy distrust for large organizations.
The distrust seems valid to me, but it unfortunately seems to lead to a bunch of confirmation bias.
The distrust seems valid to me, but it unfortunately seems to lead to a bunch of confirmation bias.
That problem is different: whitelisted Apple traffic is not able to be dectected/stopped by third party software using the new userland network APIs (that replaced kexts)
>whitelisted Apple traffic is not able to be dectected/stopped by third party software using the new userland network APIs (that replaced kexts)
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.
https://news.ycombinator.com/item?id=25113039
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.
https://news.ycombinator.com/item?id=25113039
You have poor reading comprehension if you think thats what I said.
> For example, the keyboard sometimes takes longer to wake up from sleep mode
Apple computers phone home before waking up the keyboard from sleep? What in the world?
Apple computers phone home before waking up the keyboard from sleep? What in the world?
How else would they be able to protect the user from an unauthorized screen replacement?
When are they going to require an always-on camera to protect the user from potentially being held at gunpoint? Or is Apple confident they're the only party that gets to do that?
There has been malware that pretends to be a HID driver and function as a keylogger and/or execute arbitrary code. While Apple may be being overly cautious here, it's not entirely unreasonable.
I wonder how one might be able to install a HID driver whilst the machine is suspended.
[deleted]
AFAIK it's nothing to do with mullvad specifically. Using the generic openvpn/wireguard client (or other VPN service's client that are based on those clients) should also be fine. The only thing that might be an issue would be VPN apps that implement split/per-app tunneling.
One thing about this: Ok, Apple is not that evil to use my data(?), is not that bad because whatever, but:
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?
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?
You can turn off the internet and freely use your Mac. The network dependent features are smart enough to know you are offline and not impede you.
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.
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.
While I never used anything Apple, I’m a Mullvad user. This just popped up in my RSS feed and I thought it would be relevant.
While I'm very grateful for the research that Mullvad has done to reassure us that VPN's can still be effective and work as normal, it's still a serious enough issue for me not to "upgrade" to Big Sur. Especially after reading about the Little Snitch fiasco as well. Both tools are essential for a proper internet experience.
Mullvad is a fantastic provider!
I am using Mullvad (3 years in a row). The app updates are regular and interface for switching countries is clear and functional. Highly recommend.
You can also use Mozilla VPN to support Firefox and use the same service (it's done through Mullvad). Downside to Mozilla though is no Mac or Linux client
mullvad app overwrites firewall rules and allows all outgoing connections..
https://github.com/mullvad/mullvadvpn-app/issues/2171
https://github.com/mullvad/mullvadvpn-app/issues/2171
varispeed(2)
This is just an ad.
Is there a difference between disallowing an action and denying it? I think so, and that word choice matters. I see this pattern everywhere. Do you disallow someone on FB, or do you block them? Does iptables use disallow as a keyword? I do see BLOCK and DROP though.
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.
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.
Apple making some of its components bypass application level firewall might need to occur given the reality that a modern os is a decentralized system -- but I really think the set of such code with this functionality should be minimized to the absolute smallest possible surface area -- and this behavior should be confined to a tiny set (or even a single) of system components ... "low latency clock coordinator component" or whatever the true architectural reason for the system to require unfettered network access is ...
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 ...
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 ...
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?