ProtonVPN Additional note: Killswitch failure and IP Leakage on Linux

[dngray (Daniel Gray)]

@jonah

@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.

@ignoramous

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.

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.

I think you’re all missing the main point, the hardware on a router is fundamentally different in the way it works. It has multiple network interfaces ie IN and OUT. The VPN tunnel is just another exit, and can be treated as another OUT interface. This makes developing a ruleset a lot easier.

The actual router itself doesn’t have a kill switch, it is allowed to route to wherever it likes, and that’s okay because the router doesn’t generate much traffic by itself. It might check an NTP server or system update server but that’s about it.

The decision logic then comes down to “if the packet comes in on this interface” then “i put it OUT on XXX”. A rule then will then select on the IN interface as well as VLAN ID.

The VLAN ID can either be tagged on the device (advanced network setting) or by the port on the switch, or WLAN access point. The packet has already left the macbook so the VLAN tag cannot be stripped by any software running on it.

The problem when you try build a kill switch into an application on the client using it is, in the case of rule based firewalls, multiple things might mess with it. The VPN software has no way to know.

The second issue is that still has to be exceptions, a kill switch must allow access to the VPN provider’s API servers otherwise when a user logs in it, won’t be able to pull the latest wireguard configuration files (those have the keys in them).

The third issue is that because there’s exceptions and nothing really enforcing anything besides the firewall should something change, the kill switch might simply be broken. That is also where you get issues with software directly binding to an interface its not supposed to.

A fourth issue is that when changing servers I doubt any of these clients actually clear out all existing established connections from the routing table. That I haven’t tested.

The TLDR of that is there’s many more variables and things that can go awry, that its really difficult to test for.

What it does sound like is Proton is developing a method which based on the description:

@Proton_Team

What we are doing instead is baking the protections into the network stack itself to ensure that the protected tunnel must always be retained even when the connection is interrupted - either accidentally, or during server switches. This new cross-platform network architecture was the main thing that we were working on during our Autumn/Winter roadmap cycle

is actually the correct way to do this. It means it will work on iOS properly too. I would not be at all surprised if Apple is not involved behind the scenes, as there may have needed to be changes on their end as well - that is speculation, we really can’t know until we see it.