What should we require of VPN providers on macOS?

[jonah (Jonah Aragon)]

The discussion surrounding Remove ProtonVPN - #332 by ph00lt0 is so random and all over the place, that I am not even going to attempt to sort it out and try to move some posts over here. See:

Remove ProtonVPN

They may make it so it’s user land tools don’t exist, as that is the case on iOS you cannot configure pfctl. As for jail breaking that isn’t going to work on any remotely modern device and certainly something a VPN provider can’t depend on. Cite this if you are going to assert it please. I can not find any statement by Apple that they are planning to remove pf. It would be crazy if they did considering it’s what their own system services rely on under the hood. They expressly say in TN3165…

I think the main question is: Should we require providers to use hacky workarounds like pfctl filters on macOS instead of standard tools the OS provides?

It feels like the answer is probably no, but if anyone wants to continue this discussion then this is a fine place to do so.

[ph00lt0]

Another source with these conclusions earlier was here Remove ProtonVPN - #204 by 6sxbi

[Cyber-Typhoon (Always leveling up)]

Previously, I commented that I felt a warning should probably be added for users running Proton VPN on macOS. I think that point is still somewhat reasonable (maybe even for Linux as well, although Linux is a different discussion since systems there are extremely modular and users can harden things in many different ways).

However, I think we should also give attention to the following comment that was added earlier:

@dngray

its obvious why ProtonVPN chose to do it the supported Apple Way rather than relying pf which has other known issues. Apple very clearly say not to use pf for widely distributed applications. Mullvad and IVPN chose to disregard this, and may find themselves in the same situation a year or two from now.

This is actually a very valuable contribution because it clarifies a lot of the context behind what we have been discussing.

If I understand it correctly, the situation roughly looks like this:

ProtonVPN’s stance:
“We follow Apple’s official networking frameworks because that is the supported and future-proof path, even if the APIs are sometimes less flexible. This may lead to limitations in how certain features (like a strict kill switch) can be implemented on macOS.”

Mullvad / IVPN’s stance:
“We are not fully comfortable relying on Apple’s framework for a guaranteed leak-proof kill switch, so we use the lower-level pf firewall to enforce stricter guarantees, even though this approach is not officially supported by Apple.”

This discussion changed my perspective a bit. Initially, I thought ProtonVPN was the problem because it was the only one of the three not promoting the stronger kill switch approach. But after understanding what is required to achieve that behavior on macOS, the situation seems more nuanced.

Seen from that perspective, ProtonVPN may actually be somewhat penalized for following Apple’s current guidance. That makes me wonder: should ProtonVPN really be removed from the recommendations for playing by Apple’s rules?

At least from where I stand now, and not taking sides, this looks less like a ProtonVPN issue and more like a limitation (or design choice) in Apple’s networking model.

Am I missing something?

---

<mod edit: removed off-topic section, DM’d details>

[ph00lt0]

I am glad it changed your perspective. You understand it correctly here.

[privacycarrot]

@jonah

hacky workarounds like pfctl filters

What prompted you to say that a system firewall is a “hacky workarounds”? This is a kernel subsystem and how people are doing packet filtering since as long as I know. macOS is not unique here and Network Extensions are a no way a replacement for a firewall as they suit different use cases.

Given how this thread is being started from a false premise, I don’t see this is going to achieve what it’s supposed to achieve.

@ph00lt0

Another source with these conclusions earlier was here Remove ProtonVPN - #204 by 6sxbi

Trust me bro is not a source, and claims from this post were already refuted in the thread.

[ph00lt0]

@privacycarrot

Trust me bro is not a source, and claims from this post were already refuted in the thread

I understand this is a language issue. But source has a different meaning in this sentence. I find this one a bit funny so don’t worry.

[jonah (Jonah Aragon)]

@privacycarrot

hacky

Because you have to hack together a solution with unsupported features instead of a well-defined API, using pfctl in a consumer application is by definition a hacky workaround. It’s not a judgemental statement, it just is what it is when Apple says:

Do not use Packet Filter in a software product that you distribute to a wide audience.

The question in this thread is whether products should use Packet Filter anyways, regardless of Apple’s advice, which I think is what you’re arguing, so I don’t understand why you’d think there’s a false premise here.

[privacy.slouchy]

I might recommend an alternative solution: explicitly recommend against Apple systems on the OS recommendation page, for threat models that include network surveillance

Proton is a symptom, not the cause: Apple does not support robust network proxies for privacy / anonymity:

• The Apple recommended solution is leaky, as shown by Proton’s implementation
• The implementation used by IVPN/Mulvad violates Apple dev guidance, may be unsustainable

Question I am trying to answer: is this issue specific to VPN clients? What about other proxies, like Tor?

[jonah (Jonah Aragon)]

I would imagine TorVPN would suffer from this issue. This is typically why you’d want to use Tor Browser for browsing Tor, which can better control the network stack it uses internally, instead of offloading all networking to the OS.

I think I agree but I might instead place a warning about macOS on the VPN Overview page. I am not sure if there are any known issues of using Tor Browser on macOS, besides just the generic Tor Browser issues that Whonix solves, so there are some network surveillance use-cases where macOS would be good enough.

[privacycarrot]

PF is well supported on macOS. Apple may have a lot of reasons to say what they are saying but this is not necessarily relevant to what VPN clients want to do. Not to sound rude but please do some research before claiming something.

[ph00lt0]

If you read the links mostly @dngray posted you would have seen that apple is actively advertising that developers must move away from pf because they seem to want to remove support for it.

[jonah (Jonah Aragon)]

@privacycarrot

Apple may have a lot of reasons to say what they are saying but this is not necessarily relevant to what VPN clients want to do.

Once again, that is exactly what this thread is about. Since I think this is well established by both of us, let’s move on.

@ph00lt0

because they seem to want to remove support for it.

I’m unsure this claim can be backed up by those docs tbh

[privacycarrot]

@ph00lt0

because they seem to want to remove support for it.

Not really. I read that link and posted a reply in the original thread: Remove ProtonVPN - #337 by privacycarrot

[ph00lt0]

If you’re currently shipping a product based on PF, plan to migrate it to a supported API.

TN3165: Packet Filter is not API | Apple Developer Documentation

[jonah (Jonah Aragon)]

I’m extremely unsure why you are confused reaction still, but anyways yes I agree with you lol

@privacycarrot

I don’t think you can draw this conclusion from this TN, and it’s more of an uneducated guess rather than a definitive thing. The beginning of that article clearly explains why Apple says it shouldn’t be used in shipped apps:

macOS implements the BSD Packet Filter mechanism. This has two expected use cases:

• As an implementation detail of various system services built-in to macOS
• As an advanced feature for users, site admins, and so on

It is not considered API. <…>

Network Extensions are indeed much more maintainable than PF rules for app developers as they allow you to update your extension reliably without affecting the rest of the system.

@privacycarrot

I’d be extremely surprised if they just removed a firewall from their base system without providing an alternative. Especially given they need this functionality themselves and they know users need it as well.

[privacy.slouchy]

Generally, same page

If this packet filter / network extension issue impacts network proxies beyond commercial VPNs, such as Tor routing,

then I feel a warning on the VPN page is insufficient, and a warning needs to be placed at the OS level,

else your VPN-level warning addresses all issues

Im digging through the specs for Apple Tor proxy tools, probably won’t have the time to find a conclusive answer tn, maybe some wayward network enthusiast picks up the torch & runs with it

[privacycarrot]

@jonah

I’m extremely unsure why you are confused reaction still, but anyways yes I agree with you lol

Sorry, a misunderstanding on my part

[jonah (Jonah Aragon)]

I do think it still remains a valid question here whether we should say VPN clients should always use PF on macOS, even if Apple isn’t going to remove PF. Especially because, as you also note…

@privacycarrot

I also believe macOS apps can’t manage the firewall from within a sandbox, so an app which relies on it can’t be distributed on the Mac App Store.

…such a requirement would mean we could never recommend a VPN distributed on the App Store. I’m not sure that makes sense for us.

[ignoramous]

@jonah

While this is no longer a technical issue for us, because of the criteria change above

I don’t get why this is no longer a technical issue?

From Apple’s documentation, it seems that includeAllNetworks flag will prevent the traffic leak scenario on exit server changes that Proton is hitting on macOS?

Even then, it isn’t clear why Proton’s macOS app should leak on exit server changes at all, without includeAllNetworks flag set. If Proton’s using WireGuard… nothing about the official implementation strikes me as requiring recreating the VPN tunnel (which is where I presume the leak comes from) on exit server changes.

(… with the caveat that I’m not an experienced iOS developer) It seems like enforceRoutes is another ‘killswitch’ like API that may work.

@ignoramous

@ph00lt0

Apple’s architecture makes it nearly impossible to make a functioning kill switch.

This is a misleading statement. NetworkExtension docs do mention that for VPNs using includeAllNetworks (a form of a ‘killswitch’) will prevent traffic from bypassing the VPN for advertised routes, for example, when apps may “scope” their traffic to a particular network interface

I’m aware of Mullvad’s blog post that claims that the includeAllNetworks flag results in permanent connectivity loss on iOS when the VPN app that sets the flag is killed by the platform’s app -updater.

[jonah (Jonah Aragon)]

I remain a little confused about this, because Proton is using includeAllNetworks (unlike Mullvad?) but we still see this behavior.

@ignoramous

If Proton’s using WireGuard… nothing about the official implementation strikes me as requiring recreating the VPN tunnel (which is where I presume the leak comes from) on exit server changes.

I also agree with this being possible, and have been meaning to test the actual WireGuard client to see if it has the same issue switching between servers.