top | item 40279966

(no title)

morattisec | 1 year ago

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.

discuss

order

wolverine876|1 year ago

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|1 year ago

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|1 year ago

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|1 year ago

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.

dylan604|1 year ago

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.

wolverine876|1 year ago

> found the actually relevant information extremely annoying to find

Skip down to the DHCP section?

idkdotcom|1 year ago

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|1 year ago

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|1 year ago

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|1 year ago

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.

barbariangrunge|1 year ago

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