NeatNit

joined 10 months ago
[–] NeatNit@discuss.tchncs.de 3 points 6 months ago* (last edited 6 months ago) (2 children)

I think by client you mean the device and operating system, which is correct to my understanding, but it's confusing because 'client' can also mean the VPN client software which is often supplied by the VPN provider, and that's what I first think when you say client. So with that in mind it sounds like you're saying "it's not about the VPN but the VPN software" which obviously comes from the same provider.

I have not looked into it so you probably understand this more than I, but from the sound of it the VPN software can be built to detect, prevent or counteract the exploit even on affected systems? In which case, even though it's an environment issue it can still be resolved by the VPN provider.

[–] NeatNit@discuss.tchncs.de 11 points 6 months ago (4 children)

https://arstechnica.com/security/2024/05/novel-attack-against-virtually-all-vpn-apps-neuters-their-entire-purpose/

Interestingly, Android is the only operating system that fully immunizes VPN apps from the attack because it doesn't implement option 121. For all other OSes, there are no complete fixes. When apps run on Linux there’s a setting that minimizes the effects, but even then TunnelVision can be used to exploit a side channel that can be used to de-anonymize destination traffic and perform targeted denial-of-service attacks.

I did not look into that setting that minimises the effect but from the way it's written it sounds like this isn't used by default, so by default you're still vulnerable. Add even if it's on, there's still a side vulnerability.

[–] NeatNit@discuss.tchncs.de 6 points 6 months ago (6 children)

Linux is affected.

[–] NeatNit@discuss.tchncs.de 2 points 6 months ago

Depending on what its purpose it, it likely needs to be unencrypted (or at least decryptable by the operator without the user's key) in order to function. A recovery email likely needs to be used precisely when you don't have your password, so it can't work if it's encrypted with your private key.

I suppose this isn't necessarily obvious to a user but it's not a flaw or fault of Proton, it's unavoidable if a recovery email is used. Note that it's optional to add one (see article update).

[–] NeatNit@discuss.tchncs.de 8 points 6 months ago

That's significantly worse privacy-wise, since Google gets a copy of everything.

Obviously, but I still haven't gone through all the things I've ever signed up to and changed my email to the proton one. When I sign up to new stuff I use Proton, this is a necessary step for transition... And one that is likely to stay in place for a very long time since I'm going to keep procrastinating it.

Unless you're using proton mail anonymously then you don't need to consider the recover email as a weakness.

Excellent point.

[–] NeatNit@discuss.tchncs.de 2 points 6 months ago

FYI email contents were not decrypted or turned over to police, as far as I know Proton's E2EE is still as good as whatever system you're using. Proton doesn't have the keys to decrypt your emails, it never did. What they have access to is metadata that is necessary to function when your private key is unavailable - e.g. your public encryption key used to encrypt incoming emails from non-Proton sources, or in this case, a recovery email address (I don't know what the recovery process entails and whether it can restore encrypted emails).

[–] NeatNit@discuss.tchncs.de 13 points 6 months ago (2 children)

Don’t put any recovery info on Proton

About that. I'm still making the transition from gmail and currently most of my mail still goes to gmail first and gets forwarded to Proton through their easy switch process. Surely this is just as up for grabs as a recovery email, right?

FWIW I'm not likely to be investigated any time soon so I'm not worried either way.

[–] NeatNit@discuss.tchncs.de 9 points 6 months ago

Not really, Linux is still vulnerable and there is a mitigation but it opens a side channel attack.

[–] NeatNit@discuss.tchncs.de 22 points 6 months ago (4 children)

This technique can also be used against an already established VPN connection once the VPN user’s host needs to renew a lease from our DHCP server. We can artificially create that scenario by setting a short lease time in the DHCP lease, so the user updates their routing table more frequently. In addition, the VPN control channel is still intact because it already uses the physical interface for its communication. In our testing, the VPN always continued to report as connected, and the kill switch was never engaged to drop our VPN connection.

Sounds to me like it totally works even after the tunnel has started.

[–] NeatNit@discuss.tchncs.de 1 points 6 months ago

This was posted a few hours before your comment by a user named neuropean. It's absolutely amazing!

[–] NeatNit@discuss.tchncs.de 4 points 6 months ago (1 children)

They could not care less, this is so ancient and irrelevant.

[–] NeatNit@discuss.tchncs.de 4 points 6 months ago (1 children)

How is this so good hole crap

view more: ‹ prev next ›