Revisiting VPN always-on/killswitch hardening

hemlockiv

The VPN options for "Always-on" and "Block connections without VPN" are sources of constant confusion, both for GOS users and the Android userbase at large. The core issue is:

"Block connections without VPN" disables all non-tunneled traffic, which also disables split-tunnel features
"Always on" only makes the VPN turn on automatically at boot or quickly reconnect when disconnected
There is NO KILLSWITCH FEATURE in aosp currently that blocks all network traffic only when the VPN is disconnected.

A true Killswitch is a valuable and necessary aspect of cybersecurity: For a system with a split-tunneled VPN (for which there are many valid use cases), if the VPN disconnects unexpectedly, it should [at least give users an option to] disable all outbound traffic to prevent leaks, even if it means blocking some connections that are normally permitted outside the tunnel. Instead, the current implementation means that a VPN disconnect will immediately send all connections over the public net, and users have NO option to prevent it while protecting their split-tunnel setup.

My solution is simple: An additional Killswitch toggle that revokes Network permission for all apps (except the selected Always-On VPN app, since we presumably want to be able to easily reconnect that.) To avoid confusion, the toggle names could be slightly reworded, perhaps something like,

Always-on VPN (Stay connected to VPN at all times)
Route all connections through the active VPN (Warning: This option disables split tunneling)
Killswitch (Block all network access if the selected VPN is disconnected)

argante

hemlockiv I completely agree with what you wrote and also think a killswitch toggle is desirable. Personally, I would simplify it greatly and use "Block connection without VPN" by default, but also add the ability to add exceptions for applications I trust and that must run outside of the VPN. Signal/Molly can work via TorVPN, but the voice connection must be P2P. Currently, we have two extremes – "Block connection without VPN" enabled or disabled. The result is that if you want to use voice calls normally, you have to disable "Block connection without VPN," and in effect, instead of preventing leaks, we completely allow them.

lackofhumor

hemlockiv
VPN settings Always On and Block connections without VPN together are already the OS way to prevent leaks from your system and they work really well.

Split tunneling is not an OS' feature, it's merely an app implementation.

You are asking to implement an OS wide killswitch that is basically the equivalent of Split Tunneling and/or reads the trusted apps list from a user app (the VPN app).

I guess the correct thing to do is to stick to what the OS is capable of (which is very powerful, btw) and try to adapt based on that.

If you have enough apps that do not work with your desired VPN, you can create a private space, or a work profile, or a second user to manage them.

Sometimes using the website instead of the app (or vice versa) is already enough to use the service, even if (I understand) there might be some inconvenience.

hemlockiv

I'm aware this feature has been discussed before, but fruitlessly, as it appears a miscommunication with a moderator, either about the intended purpose of the hardening or the current vulnerability with data leakage, may have led it to being prematurely marked 'Solved' and overlooked by the devs.

hemlockiv

argante Oh absolutely! I personally think the best implementation would be to have a list of all apps to toggle as going through the VPN or not—essentially making split tunneling be a feature of the OS rather than of the VPN provider. That list would also let VPN-excluded apps retain connectivity in a Killswitch scenario. But I recognize that implementing that would be a lot more work; I deliberately made my proposed implementation as simple as possible.

argante

hemlockiv I personally think the best implementation would be to have a list of all apps to toggle as going through the VPN or not

This isn't the optimal solution—unfortunately, that's often how it's done. Look at it from a computational perspective—if you have everything blocked by default and those individual applications excluded from the VPN (exceptions), you only have to check those exceptions, of which there will probably be a few, and nothing more. So, you can do a quick check and block the rest. Most often, it's done the other way around, meaning you have a list of all applications. In this case, the check would have to run through all applications, which is much more expensive.

argante

hemlockiv By the way, remember that there is RethinkDNS, which gives you a lot of control over these types of connections.

hemlockiv

argante hemlockiv By the way, remember that there is RethinkDNS, which gives you a lot of control over these types of connections.

No, it doesn't. We're talking about VPNs and split tunneling. RethinkDNS is just one of many DNS firewalls that use the profile's VPN slot, but if Rethink crashes or gets disconnected for whatever reason, you end up with the exact same problem we're trying to address here.

Also, not sure what you mean about the computational perspective. The toggleable app list I described is just the user-facing interface; it is what would determine the shortlist of apps permitted to circumvent the VPN. Granted, I don't know much about CS and low-level resource usage considerations, so I may be misunderstanding your first comment.

argante

hemlockiv Here's an example. The point is not to check all possible applications if can allow to bypass a VPN or not. This would be very resource intensive and drain the battery.