[morattisec]

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.

[banister]

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.

[morattisec]

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.