Hacker News Reader

Comment by EasyMark | Hacker News Reader

I haven't seen anywhere that said there can be a "fix" for this outside of not allowing "option 121" to be in use at all the DHCP server. Is there no way to mitigate this in the VPN client, or is it simply too fundamental to the way the networks work that there is and never can be a "fix" on the VPN client? I wouldn't expect a malware laden network's "admin" to ever fix this or even hear about it.

View on HN

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.

The "side channel" is silly. You assume someone is hitting the same endpoint over and over and over and with significantly high traffic that it rises above the noise.

Did u even do any of the math required to demonstrate it can actually work in a reasonable time frame? Did u clearly list the very onerous assumptions required to pull it off?

This whole thing is silly.

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 side channel attack is silly and impractical. You know it's silly. I know it's silly. Let's quit pretending.

The firewall rule is 100% sufficient to defend against this exploit. All good VPNs already provide it by default. It's not deep. They're just routes.

Please stop the FUD.

Side channels are a huge danger. An example is cryptographic functions have been cracked because of timing differences based on the key or data being encrypted. This is why cryptographic ciphers are implemented in constant time code (i.e. code that always runs in the same amount of time regardless of its input).

I'm talking about the specific side channel attack mentioned in their report. Not side channels generally ;)

Did you say the same thing about meltdown/spectre? Ramhammer?

Those are way more impractical but the industry still moved mountains (and killed perf) to mitigate them

Most decent VPNs are already protected against it. It's a simple firewall rule known as leak protection or a kill switch which blocks all off-VPN traffic including on option 121 routes.

This article is 99% FUD IMO.

Reply on news.ycombinator.com