ProtonVPN Additional note: Killswitch failure and IP Leakage on Linux

[jonah (Jonah Aragon)]

@Encounter5729

I would agree that this issue in itself obviously doesn’t in itself merits delistment.

I’m going to mark this topic (which is specifically about adding a warning to Proton VPN about this issue) as approved, because I think it is fairly reasonable for us to do, and it seems like the maximum that people in this thread are willing to do about this issue alone.

So, (and I’m of course requesting this of myself or the rest of the team or anyone here, not you specifically) a PR adding this warning would be appreciated.

@Encounter5729

The question is whether the entirety of those issue does IMO.

I think the question of whether we should have additional guidance/warnings about software kill switches in general probably belongs in a different topic or somewhere in Site Development > Guide Suggestions, and I think your question of whether all these minor issues should add up belongs in another thread. I’m not sure if that’s a question for a new thread where we ask this question about services across the site in general and not specifically about Proton VPN exclusively, or if it belongs in How should we handle Proton’s misleading marketing?, but it doesn’t seem to fit here.

[Encounter5729]

@jonah

think the question of whether we should have additional guidance/warnings about software kill switches in general probably belongs in a different topic or

One already exists for that

[ignoramous]

@fiqiluvo.epileto

Qubes approach makes it possible to have a messy user facing OS while having a tight and predictable network VM. With Qubes, in the worst case scenario a user facing VM will loose connection.

We can mimick this by disallowing the host OS to manage wwan and connect to the VPN router directly.

Yes, but these are what amount to ‘software killswitches’, which some here argue aren’t enough. It is my understanding that an external hardware gateway cannot act like a ‘killswitch’ if there’s no corresponding software-related killswitches installed / setup on the devices.

@fiqiluvo.epileto

Like wwan manager instructing the component to connect elsewhere or are implying firmware glitches? In both cases, it can be negated by connecting wired.

Possibly, but I was thinking of mobile networks that bypass “broadband routers”. How do you cut off an esim / mobile data on a smartphone? Very feasible with software killswitches (like turning off the baseband radio, and absent remote backdoors, it would stay off).

---

@jonah

I think we are getting caught up in minor client details here.

I feel, you’re being way too dismissive of the concerns, here. One simply cannot provide client-side guarantees (“hide all traffic from ISPs”, “hide from piracy organizations” like PG does on behalf of the public VPN providers) without client-side software to match. Client details, for VPN providers, for the kind of guarantee they claim, isn’t “minor”.

[jonah (Jonah Aragon)]

@ignoramous

It is my understanding that an external hardware gateway cannot act like a ‘killswitch’ if there’s no corresponding software-related killswitches installed / setup on the devices.

I feel this is true but the point being brought up is that the external device cannot be interfered with by software running locally on your computer, resolving interface binding issues like this. You’d also need kill switch functionality on the router to protect against unintentional disconnects, but this is an easier(?) problem to solve and (probably more importantly) seems to be typically more robust on routers compared to normal operating systems.

[ignoramous]

@jonah

the point being brought up is that the external device cannot be interfered with by software running locally on your computer, resolving interface binding issues like this.

Binding to an interface is the first thing ALL sockets (in the BSD APIs that Linux and BSDs and macOS use) do. If anyone’s ‘(software) killswitch’ is bypassed by any process merely binding to another network interface, then what they’ve setup isn’t really a ‘killswitch’. It is erroneous to call it a ‘killswitch.’

@jonah

You’d also need kill switch functionality on the router to protect against unintentional disconnects, but this is an easier(?) problem to solve and (probably more importantly) seems to be typically more robust on routers compared to normal operating systems

OSes do have a larger attack surface than a router might (especially if it isn’t also running an OS-grade kernel like Linux). That said, non-open source router firmware/software is usually not nearly as scrutinized as Linux is. Besides the upsides (you point out) of physical isolation (of the router and the device), the downside is routers also have no control over the device itself; meaning, a killswitch on the router is going to be far less effective if corresponding software killswitches are not setup properly on the device. All of that is to say, external routers are a defense in depth, but cannot overcome all limitations in/of software killswitches. The threat model that demands such a setup, imo, is out-of-scope for day-to-day use of public VPN providers (aka overkill), but probably in-scope for those using Tor.

For public VPNs, it is enough to demand that VPN clients solely rely on / compatible with the OS-provided / OS-assisted killswitch. I don’t get why there’s a sense here that Linux-based distros don’t provide anyway to setup a leak-proof killswitch (when the Linux kernel does via various sandboxing / filtering / in-kernel mechanisms). Big Cloud Security providers literally rely on these for network observability, incidence monitoring, and management.

[fiqiluvo.epileto]

@ignoramous

I don’t get why there’s a sense here that Linux-based distros don’t provide anyway to setup a leak-proof killswitch (when the Linux kernel does via various sandboxing / filtering / in-kernel mechanisms)

That is, if a user doesn’t supposedly tinker with routing in any way. Even if you run a seemingly innocent software, a leak will occur. Like docker listening on 0.0.0.0, deliberately overriding every other firewall rule, having a misleading -p 8080:80 that had lead to countless users believing it binds to localhost…

Not to mention the fact there are preexisting privileged programs, network managers, that screw VPN setups 1 2 3 all the time. For networkmanager in particular, some distros set ipv*.dns, ipv4.dns-priority to -1 by default for any new connection, making it impossible to maintain wg0 exclusivity without resorting to scripts.

Dnsmasq, systemd, but in most cases multiple privileged components all handle dns caching and forwarding on typical a Linux Desktop OS and usually forward queries elsewhere.

I can make it very comical by reciting a short list of things that do influence resolvconf alone. systemd-resolved with stub-resolved, dhclient, systemd-networkd, resolvconf/openresolv, both musl and glibc NSS, nscd, networkmanager, unbound via systemd or networkmanager or directly, dnsmasq….

Pair this with the fact Debian, Ubuntu and RHEL flavors all heavily drift from upstream and go out of their way to configure networking in the most ridiculous non standardized ways possible, and you have one of the hardest landscape to maintain VPN kill switches.

@ignoramous

Big Cloud Security providers literally rely on these for network observability, incidence monitoring, and management.

I haven’t seen any VPN client utilize caps to limit other privileged apps from interfering with crucial bits of routing rules. As of today, prebundled network daemons contribute to the majority of VPN leakage on Desktop Linux.

Businesses have a privilege of maintaining their SBOM. No k8s/traditional VPS provider/PaaS manages networking in userspace amongst their customers. I just don’t get how we can compare a server environment with desktop chaos. Terraform/cloud-init comes with a static routing on a bridge and customer just can’t screw anything. Devops and SRE engineers i know are allergic to Linux networking and want nothing to do with it unless it’s eBPF

It wasn’t uncommon to see a hardware “VPN“ blackbox being the only certified solution in the Enterprise world because a technician physically couldn’t screw terminating a network into a designated physical port just until 6-8 years ago.

A standalone router with slim and predictable dnsmasq, wireguard and firewall rules is waaay easier to manage and trust than a vpn client on a Desktop Linux OS.