So in the example we gave for the side-channel you’d be correct that “it depends”. We also wrote that it was flexible.
I do want to point out that you could deny all traffic except allow a single IP address to test the inverse in a low traffic setting. With a low DHCP lease time it’s feasible that could look like a shaky connection. This is only possible because the kill switches don’t actually disconnect the user.
There’s also mitigation bypasses that are likely to be discovered, we have a few we’re working on.
The only fix we’ve observed in the wild was limited to Linux hosts. WireGuard has documentation about how to implement that properly using network namespaces which can be used to isolate network stacks. https://www.wireguard.com/netns/ however, the VPN provider must implement it this way. In our demo we use WireGuard that is implemented without namespaces.
The other operating systems do not support that feature. The mitigations we saw were firewall based rules, which create a side-channel that be used to leak the destination of traffic.
This is mostly correct, in our POC video we showcase a lab where we go from being an adjacent host on the network to being the DHCP server.
We did this by DHCP starving the true DHCP server and hoarding all the leases. Then we serve our own and do not have to compete with the true DHCP.
There’s network protections against this such as guest network isolation or switches with DHCP snooping protections. However, those are usually on enterprises and relying on those being in place kind of removes the point of “securing an untrusted network” like many VPN providers claim.
You probably followed the advice to read from the 121 section already but if you’re sharing this others it might be helpful to link our website that serves as a TLDR + FAQ.
https://tunnelvisionbug.com/
There’s also a general public advisory there that’s supposed to be for anyone non-technical but who wants to understand the issue. All this content was also written by hand over 8ish months too, no AI was used
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.
I do want to point out that you could deny all traffic except allow a single IP address to test the inverse in a low traffic setting. With a low DHCP lease time it’s feasible that could look like a shaky connection. This is only possible because the kill switches don’t actually disconnect the user.
There’s also mitigation bypasses that are likely to be discovered, we have a few we’re working on.