[morattisec]

One of the authors here, the intention was to provide a primer of the topics since we figured this would draw people from a nontechnical background too.

That and half the information on the internet about VPNs is from VPN providers and is incorrect or not technical enough to describe how they _actually_ work.

We had a sentence in the intro that was supposed to be a hyperlink to the “hey if you know this stuff you should skip to the POC section”. I’ll make sure that gets updated/more obvious.

[wolverine876]

What I read does a great job of explaining the technology; I know it pretty well but it's great to have an updated, clear, concise, well-organized, integrated explanation all in one place. I can't imagine how long that took to make it that clear!

(Everything posted here gets similar complaints about the writing, headline, too short, too long, too hot, too cold, etc. Goldilocks is never pleased here. Welcome to HN! :)

[nonrandomstring]

Good call. For a general IT audience you are speaking to, context building really helps refresh the scene before dropping the exploit. Well communicated.

[tgsovlerkhgsel]

The PoC section doesn't explain the issue. I think a one-line TL;DR similar to the summary above would be best, e.g. "A malicious DHCP server can use DHCP Option 121 to set routing rules, which can override the routing rule used by VPNs and cause traffic to be routed outside the VPN"

(I like it that you provide the background for people who need it, but also found the actually relevant information extremely annoying to find.)

[timbre1234]

Or they could have maybe lead with that sentence and THEN given the explanation.

Too many tech people have that "I want to slowly lead you to the point like Sherlock Holmes mystery" style of writing, and it is such a time-waste. Arthur Conan Doyle was paid by the word, you aren't. Please, everyone, back to middle school: State a Thesis in your first sentence and THEN expand on it, don't force me to spend pages trying to figure it out.

[aeonik]

It's not just tech people, but any field with a high enough complexity.

The "abstract" of a journal article is supposed to contain all the key points of a science experiment including the results, but it's too rare that they do.

I think some folks are just hitting their limits, and needed more time to digest/ review their publication.

Other folks are doing it I obfuscate or pad their work, for whatever reason.

[IggleSniggle]

When you're deep enough in a thing it can be hard to know what counts as "high level summary." For example, "attackers can decloak routing-based VPNs" might seem like a good high level summary. "Attackers can decloak routing-based VPNs using DHCP rules that give priority to an attacker over other lower priority routes" might seem like it's just in the weeds enough to be misleading, or to result in a bunch of people now believing they are educated on the subject when they really are not.

Picking the right level to communicate such that you avoid clickbait journalists spreading a lie of omission/ hysteria is an art. Personally, I think we should be grateful for all the effort put into clearly communicating all the most relevant nuances; we can generalize that any high complexity field is doing its readers a service when it approaches communication this way. I'd rather the "result" be communicated at too high a level than too close to the middle (giving the illusion of understanding the nuance)

[dylan604]

Just accept you were not the target audience and skim like the rest of the world. Not every article is written for you. It's available for you to read, but was more than likely not with you in mind. Some of us still like words and the reading of them when they provide details and more in-depth understanding than a tweet.

[mindslight]

I hate tweet culture as much as anybody, but this is not the alternative. This article is so painfully long, I got bored even just trying to skim it. Reading it word for word will turn any noob into a seasoned greybeard through the sheer passage of time. If you really like words and reading them this much, I'd recommend adding some dictionaries to your reading list.

[tgsovlerkhgsel]

ChatGPT is great for providing endless reading material too!

[wolverine876]

> found the actually relevant information extremely annoying to find

Skip down to the DHCP section?

[idkdotcom]

Have you identified actual VPN vendors that are affected by this? I won't disclose which ones I use, but I would love to know if they have been affected.

[bimguy]

Great write up by the way. Even some technical people might not know about this, not all technical people are network experts after all.

[banister]

I looked at this in detail. This exploit is a nothing-burger for most decent VPNs.

A simple "leak protection" (aka Killswitch) firewall rule completely negates this attack.

All decent VPNs implement such a rule by default.

Dealing with undesirable routes (whether pre existing or pushed by a DHCP server) is nothing new or in the slightest bit hard to defend against.

If a VPN does not implement such a firewall rule already then it's likely already leaking so all this exploit demonstrates is that "A VPN without leak protection, leaks".

(I won't even mention the "side channel" attack as it's completely ridiculous)

I liked your write-up and option 121 is a little known option, so it's good to know about. But let's not pretend this thing is bigger than it is.

[CommitSyn]

FTA: Importantly, the VPN control channel is maintained so features such as kill switches are never tripped, and users continue to show as connected to a VPN in all the cases we’ve observed.

[banister]

They don't know what they're talking about. Kill switches are not "tripped" there is no "control channel".

A kill switch is just a firewall rule that is ALWAYS engaged and all it does is blocks off-VPN traffic.

It 100% will defend against this exploit.

[jcrawfordor]

Most practical VPN services don't actually implement it this way, it's a somewhat difficult and rather OS-specific problem depending on the firewall services offered by the OS. On some popular OS like mobile ones it's just not possible at all.

So just to grab an example, NordVPN's implementation does indeed work as the article presents: it monitors the VPN and disables network access for applications if the VPN connection drops. This is indeed vulnerable to any number of potential problems, and depending on the OS and user savvy you can set up better protection using e.g. the iptables owner module. It's very non-portable though, sometimes even between Linux distributions, and hard to support at scale. Actually I'd say a true "no access except through the VPN" rule is easiest to implement on Windows, but NordVPN doesn't seem to do it there either, I'm not sure why.

To be fair, it's right in the name: a kill switch is a switch that kills things. It isn't proper network policy like per-process routing tables that are, unfortunately, difficult to implement for consumer machines.

[banister]

Mobile is an exception (but they already state android is immune), let's stick to desktop for the sake of discussion, the 3 major desktop platforms: mac, win, linux :)

On mac - just implement a block everything rule with pf and then just allow traffic on the tunnel and whitelist the VPN endpoint. Boom, a kill switch that defends against this exploit. And there's no racey nordvpn-style "control channel" (if nord really works like this i have an even lower opinion of them than i do currently).

On linux - iptables (for example) - just implement a general DROP policy then override with a specific ALLOW on the tunnel interface.

On Windows - Use WFP to implement a block everything rule, then provide a higher priority rule to allow on the tunnel interface.

All three of these techniques are the recommended way to implement a kill switch and it's used heavily in the VPN industry by anyone sensible. It completely defends against this TunnelVision exploit too.

The way that you suggest kill switch is implemented (reactive and monitoring the connection?) is very fragile, racey and prone to leak, i absolutely would not trust it and it shouldn't even be called a kill switch. It's an embarrassment. :)

[jcrawfordor]

I'm not saying how it should be implemented, I'm saying how it is implemented by a number of popular VPN services. Take up the argument with them. There are VPN providers that do it right on at least some platforms, but unfortunately the way most document it it's very hard to tell without experimenting with the client to verify.

As far as I know, use of the term "kill switch" closely correlates with an untrustworthy implementation. Consider the case of Mullvad who handle this a lot better and also decline to call it a "kill switch" for that reason. And that's not to say that Mullvad is perfect, easy to find forum threads by people who had traffic leakage for various reasons. I wouldn't trust anything you didn't set up yourself.

[Borealid]

You wrote three different ways to end up with all traffic dropped and a broken VPN connection.

Traffic sent to the VPN interface gets encapsulated by the VPN client software and then routed to the Internet. If your firewall rule is dropping all traffic not destined for the VPN interface, it will drop the encapsulated traffic.

You need two (sets of) rules: one allowing traffic on the VPN interface and one allowing traffic which is already cloaked by the VPN software (or not cloaked, but used to establish/maintain the tunnel itself). That second category is a bit complicated, because you need to be able to route to the VPN server regardless of which network you're connected to - and the DHCP server tells you how to do that.

[0x457]

Let's be honest, there're 2 OSs on desktop that matter to VPN providers that provide "all-in-one app" - Windows and macOS. Both have easy to configure from your application.

On linux, well, you have to choose:

- use iptables style rules regardless of the backend

or

- use nftables style rules regardless of the backend.

So it's 3 firewalls that you have to think about.

On mobile, well, on mobile you're mostly at the mercy of the platform owner and generally can't do much. Hence, why connecting phone to "SoftAP/ether_g + VPN" device is better than a direct connection.

[Dylan16807]

> A kill switch is just

Not always. Some VPNs have a kill switch feature for closing specified programs. Hopefully in addition to the firewall rule.

[banister]

"closing specified programs" has to be the silliest thing i've ever heard. By the time you close it, it's probably already leaked thousands of packets. The leak of a SINGLE packet is already too much.

Such an "application killing kill switch" is just marketing fluff, it makes zero sense from a security standpoint.

[IndySun]

I can't check your fascinating answers but a friend is, and is beginning to concur, so I'll take theirs and your advice as closer to correct. Thank you. Next question, where have you been for so long and only back now why giving such juicy answers?

[Dylan16807]

Well to be fair I'm not sure if they kill the programs before or after disconnecting the VPN interface.

I'd sure hope it's before.

[0x457]

Let me explain how a _very_ basic setup works: you set up a firewall rules allowing only connection to VPN on all interfaces except your VPN interface.

If you're running a torrent box, then you can do whatever your OS equivalent of "this process uses this routing table". My seed box was using interfaces that were set up in dom0 and guests didn't even know about a ways to reach outside without a VPN connection being established by the host.

The point is - "such" attacks have no legs against anything beyond "OpenVPN: Getting Started" kind of server.

[barbariangrunge]

Looking at mozilla vpn, I can’t tell if there is such a setting, unless it’s just enabled by default. Can anyone clarify?

[SushiHippie]

> A VPN kill switch is a must-have for privacy reasons when using a VPN. If you are actively using the VPN to transfer data and your Internet connection becomes unstable or drops, the entire network connection on your device will be blocked to prevent your local IP address from being exposed to the outside world. The kill switch is on by default on Windows, Android, iOS, macOS and Linux and there is no setting to turn it off.

https://support.mozilla.org/en-US/kb/mozilla-vpn-kill-switch