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.
well, im not as im not using interfaces that are affected by the vulnerability (im using named, containerized network interfaces), but i appreciate the info!
it was initially reported as ‘linux & android’ were not affected.
i stand by my statement that this isnt about the VPN provider, its a client problem. so the question about Proton is moot.
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.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !protonprivacy@lemmy.world
Empowering you to choose a better internet where privacy is the default. Protect yourself online with
Proton Mail, Proton VPN, Proton Calendar, Proton Drive. Proton Pass and SimpleLogin.
Proton Mail is the world’s largest secure email provider. Swiss, end-to-end encrypted, private, and free.
Proton VPN is the world’s only open-source, publicly audited, unlimited and free VPN. Swiss-based, no-ads, and no-logs.
Proton Calendar is the world’s first end-to-end encrypted calendar that allows you to keep your life private.
Proton Drive is a free end-to-end encrypted cloud storage that allows you to securely backup and share your files. It’s open source, publicly audited, and Swiss-based.
Proton Pass Proton Pass is a free and open-source password manager which brings a higher level of security with rigorous end-to-end encryption of all data (including usernames, URLs, notes, and more) and email alias support.
SimpleLogin lets you send and receive emails anonymously via easily-generated unique email aliases.
https://arstechnica.com/security/2024/05/novel-attack-against-virtually-all-vpn-apps-neuters-their-entire-purpose/
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.
well, im not as im not using interfaces that are affected by the vulnerability (im using named, containerized network interfaces), but i appreciate the info!
it was initially reported as ‘linux & android’ were not affected.
i stand by my statement that this isnt about the VPN provider, its a client problem. so the question about Proton is moot.
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.
youre correct. its the local routing table that is vulnerable, which is usually handled by the OS.
I had not yet heard of any mitigation techniques from the vpn provider side. glad to know they are assisting with this OS/client failure.
I have no idea if they are assisting, it’s all baseless conjecture on my part! Sorry if that wasn’t clear, I thought it was