[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.

[banister]

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.

[StressedDev]

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).

[banister]

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

[hughesjj]

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