(no title)
morattisec | 1 year ago
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|1 year ago
(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
tgsovlerkhgsel|1 year ago
(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
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
wolverine876|1 year ago
Skip down to the DHCP section?
idkdotcom|1 year ago
bimguy|1 year ago
banister|1 year ago
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
barbariangrunge|1 year ago