Apple’s Private Relay can cause the system to ignore firewall rules
mullvad.net
mullvad.net
Not respecting the system firewall does seem like a flaw, but Apple has had a history of bypassing attempts at filtering network traffic. Firewalls have been blocked from working and Apple services have been made unblockable in later APIs. I'm not surprised in the slightest that Apple also bypasses your VPN to call home.
I don't know if this is a problem, though. If you buy Apple, you let Apple make the decisions for you, that's how the entire ecosystem is designed. You must trust Apple unconditionally and accept traffic sent home to adhere to their privacy settings, or you should not run macOS at all. Try to run Windows or Linux on it if you've bought your computer for the hardware quality, though the M1 makes that nearly impossible without sacrificing user experience.
A computer does what its owner whats it to do. And when Apple or another company is directing its actions, tells me that what I have is a rental.
Either relinquish control, or put it on the market with the real name. It's not a sale.
As an aside, I’d also like to subscribe to “No as a service”.
What is apple meant to do? Just not provide the service at all?
Because private relay is vastly superior to a VPN for web content, which is what matters to most users?
PF is not the thing that does actual networking, on any OS.
As far as I understand networking and firewalls like PF, you essentially have the lowest level, where the kernel/driver puts bytes onto the channel.
Then you have the various userspace networking interfaces for various transport mechanisms, TCP, UDP, QUIC, etc
Each one of those is doing
<transport protocol specific thing>
<send the bytes>
The <send the bytes> part is below where your firewall stuff is going to happen, so I'm going to guess (I have never written kernel level networking because that stuff seems like relentless misery) that it means that every transport implementation has to independently have some code that looks like packet_data = <build the packet>
if (auto firewall = current_firewall()) {
if (firewall->should_block(packet_data))
return E_BLOCKED; // or whatever
}
kernel_send_the_bytes_yo(packet_data);
Or something like that, all super super pseudo code of course.Anyway, if that general concept is vaguely accurate then that means every time someone brings up a new transport protocol that another opportunity for this to get missed. Not saying its good that such a thing is possible, or that not catching it is ideal, just saying it seems like a plausible path to this kind of bug happening - Hell, I'm not even sure it would be the first case of an OS missing PF, I have some vague recollection from the distant past?
What happens when multiple features in conflict are both turned on is a classic UI problem. Quietly doing a compromise between them is the exact kind of opinionated default that I am talking about.
You don't know that for sure, unless you know exactly how the Apple side of PR works, there could well be circumstances where that would cause problems. At the scale Apple operates at they must come across all sorts of weird an unusual configuration combinations.
There are 0 reasons for enabling private relay and also configuring a VPN, yet that's what the user did. In any case this is documented and Apple provides instructions how to block it.
The issue here is thinking that the VPN subsystem and firewall subsystem and how they work are the product from Apple's point of view. They're not, they're just implementation details. For Apple the intended high level user experience is the product, in this case the UX of the private relay service. If they need to bypass some subsystem to achieve a better more consistent high level user experience then that's what they will do.
If you've enabled Private Relay then it's doing exactly that.
With Mac, you can usually handle the user-space scenario. Not so much the kernel-space one.
That's what's great about Linux. You don't have to submit to somebody else's will if you don't want to. It takes more effort, but good things always come at some cost.
Apple is arguably engineering computers and OS UX "correctly," e.g. better for most people.
For the technically-minded Linux is an option, but for everyone else Windows at least allows you to firewall off any domain you choose. Sure, you'll probably break Windows Update in some way, but the Windows kernel doesn't try to bypass your settings (yet).
I can't tell if you being extremely sarcastic or lack experience running both of these OS's...
They got used to the system quickly and used it for 4 years, until the OS went out of LTS and I told them not to use it anymore… but still, they have no idea what a terminal is, no tech savvy, but still used it for their basic use-case for 4 straight years without issue! I didn’t even have to help them after the initial install. Couldn’t have been easier.
If you're medium tech savvy then you run the risk of knowing how to break something but not fix it.
My Windows 10 install may be full of spyware I need to block, but the software works pretty flawlessly in comparison.
With the terrible state of Nvidia's drivers, my Linux install has kernel panicked more often than my Windows box has BSOD'd.
Reliability-wise, desktop Linux is boringly stable these days as long as you don't insist on the bleeding edge by using Arch or Debian unstable.
The MS Office situation has gotten much better with the rise of online office suite web apps, including Office 365, as well as professional desktop software like SoftMaker's closed-sourced and misnomered FreeOffice[1] that has great compatibility with files written in MS Office's formats.
Lack of Photoshop is a problem, but if you're doing animation, special effects or video editing work, Linux has you covered because companies release Linux versions of their workstation software like DaVinci Resolve, Houdini, Autodesk Flame, Blender, Lightworks etc.
My colleagues have implemented and validated firewalls on MacOS without issue.
The private relay feature is worth being aware of, but it's irritating for users to deal with overzealous and clueless admins who think that locking down systems by disabling features like this can "increase security". It just ends up getting in the way of getting work done without any real benefit.
(And yes, I often end up annoying myself by blocking stuff I myself would like to access at work. But that's my job.)
https://developer.apple.com/support/prepare-your-network-for...
mask.icloud.com mask-h2.icloud.com
If you really ‘need’ to block that kind of connection the onus is on you, not on the services.
I feel like rules such as yours are a pre smartphone era thing, when I had to use the company laptop to get online away from home.
The question about if it's in the network owners purview to inspect depends on the network and traffic. It could also be illegal privacy violations.
I understand that ad companies have a vested interest in circumventing this and trying to move internet standards to opaque protocols, but until that particular fiefdom is unseated, we have to make reasonable tradeoffs.
In the meantime, we block a massive amount of malware by blocking their ad domains.
I think the point here is you write on their equipment. I was talking about cases where the network owner don't control the endpoints, that is allowing private devices to connect. snooping in that data can be problematic.
This is a massive [Citation needed]. Do you have a court precendence case where you can prove that admins have the right to snoop through private and sensitive data of users that are just connected to some network?
I nearly lost my mind when I got a DMCA notice from our ISP. I never thought I’d need to lecture a team of professionals that the consequences of losing our office internet would be significant to the business.
this interests me because a few years ago i was subjected to a government imposed firewall https://thewire.in/government/kashmir-internet-whitelisted-w...
and i tried my best to bypass this but i did not have the energy to fashion a touniquet of sorts. i did end up spinning up a free amazon vps because apparently "amazon website" was unblocked and that forced them to allow aws. i ended up simply using ssh -D to the ip of the vps. that worked for a while but it was not fun... the connection would drop frequently but otherwise it was a POC.
my point is, when we are talking about a hostile adversary like your government that is out to get you, regular "vpn" does not work, in my case, i tried every darn thing but until i came up with my thing, i could not get access to regular internet so for the next time, what can i do?
When I moved to university, bandwidth was limited in the dormitory to 1mbps/user (in 2016…) This was unacceptable to me, but we had a private link (non-internet) to the campus with virtual desktop infrastructure that had no such limits :). ssh -D immediately gave me 500mbps download to my dorm room, and I guess this sort of thing is probably why I think of ssh -D and running on port 53 etc to evade this sort of thing. Public education in the US can function pretty well as a government out to get you in terms of digital freedom :)
yeah, i guess for some time, cisco was called out by news outlets for helping the government impose the firewall which the company later denied but the damage was done by then so it didnt really matter, still, i think this just slipped from their minds, a random port, somethimes 80, 8080, 3400. it was fun (well considering the circumstances) with the added risk of incarceration if caught and many were unfortunately so yeah
A major advantage of this approach is that it leverages a port and protocol that’s rarely blocked, and if 53 is blocked, you can generally still use the approved local dns servers for your data-carrying queries.
These days, it looks like there are at least a few well-known pieces of software to do this, e.g. https://github.com/yarrick/iodine
"It is worth noting that Private Relay (mostly) disables itself as soon as any firewall rule is added to PF (the system firewall on macOS devices). The Mullvad VPN app does add firewall rules. Once you connect the Mullvad app, Private Relay announces that it has disabled itself. We see no correlation between user traffic and the leaking packets. We believe they are just some heartbeat signal calling home to Apple. We do not know what information is transmitted to Apple, but since the destination is Apple servers, it is a strong signal to your local network and ISP that you might be a macOS user."
It is very bad indeed; not even Microsoft dares to do this in Windows (you can still very much block any network request from any part of the system via firewalls or DNS ad-blockers).
From your link:
> Objective Development, the developers of Little Snitch, also writes about the discovery - and that they take it for granted that Apple will correct it. (Update, 14 January 2021: Apple indeed appears to have removed the whitelist exemption in macOS Big Sur 11.2 beta 2.)
Unclear if that's the case on iOS though.
What happens if you enable two VPNs concurrently today?
Private relay and VPNs serve significantly different purposes - private relay is very clearly http[s] focused to the extent that I recall it doesn’t cover most traffic?
I tested this on iOS and Private Relay does not turn itself off when a VPN is enabled.
Does your VPN possibly not offer a default route?
If the apple documentation says it does, that would seem like an obvious bug, but I'm curious whether the apple docs do say that, or there's a general assumption of that being the case?
Oh, as I think of it, did you test the UI switch position or network traffic? I could believe the following behaviors:
* UI switch turns off, private relay continues to carry traffic
* UI switch stays on, private relay continues to carry traffic
* UI switch stays on, private relay does actually turn off
All seem like entirely plausible bug behaviors, and it would be nice to know which it was (UI off + iCPR on would seem to most overtly be a bug)
I don't believe it's possible to have more than one VPN configuration be enabled simultaneously.
[1] https://developer.apple.com/support/prepare-your-network-for...
> We do not know what information is transmitted to Apple, but since the destination is Apple servers, it is a strong signal to your local network and ISP that you might be a macOS user.
isn't this trivially evident with all your traffic being tunneled back to apple as well?
As with most of the stuff pulled from FreeBSD, it was pulled around the year 2000, usually with no updates from upstream, and often with few updates from Apple. Pf's synproxy doesn't really work on macos, and is unlikely to get fixed.
At least it’s still beta!
The product seems to be fraught with security issues for Apple customers and others.
Then turn on Airport mode on your cellphone.
Sign on to your WiFi.
IP address Privacy, pretty much assured (assuming you have your own backend WireGuard and remote VPS-based gateway. )
Otherwise it sounds like sound advice for any device if you have the threat profile to warrant it.
Who ever said about running your own exit node on your own VPS?
We got other ways to established an exit node. Is an entrance node, this VPS.
But it is heady and pointless … for a small fry.
Also use it as a backup for if the home ISP goes down.
The headlines said "apple is refusing to unlock a terrorist's iPhone, but if you did your homework, it was actually the aboe first sentence that was happening.
That's pretty pro privacy. I assume Google has already done this for them, perhaps without even being asked.
Google's and Apple's policies are basically the same when it comes to sharing data with the government... they both comply with secret laws (thanks Snowden).
Mullvad is installing a rule to essentially disallow any non-VPN'd traffic to prevent leaks. But iCloud Private Relay is not being stopped by that rule.
[1] https://arstechnica.com/gadgets/2020/11/apple-lets-some-big-...