Thread - Nostr Hypermedia

👀

William K⚡Santiago🔑☢️

Mullvad VPN has confirmed the existence of critical DNS leak problems in certain Android VPN apps due to inherent bugs in the Android operating system. The issues can occur in multiple scenarios, such as if the VPN is active without any DNS server configured, or for a short period while the VPN app is reconfiguring the tunnel or being force stopped/crashing. These leaks can expose users' browsing history, location, and ability to bypass internet censorship, even with the "Always-on VPN" and "Block connections without VPN" settings enabled. Mullvad has reported the issues to Google and is implementing a workaround, but the problems should be addressed at the OS level to protect all Android users. DNS traffic can leak outside the VPN tunnel on Android https://mullvad.net/en/blog/2024/5/3/dns-traffic-can-leak-outside-the-vpn-tunnel-on-android Does it apply to ios devices? No, the DNS leak issues described do not apply to iOS devices. The search results specifically mention that the problems stem from bugs in the Android operating system itself, and only affect certain Android VPN apps. The Mullvad VPN app for iOS uses the "on-demand VPN" function which acts as a kill switch when the VPN is connected, and should not leak traffic. The article also notes that while there are some potential privacy issues with iOS, such as traffic to Apple services bypassing the VPN tunnel, there are no issues analogous to the Android DNS leaks described. So in summary, the critical DNS leak vulnerabilities are limited to Android devices and apps, and do not impact iOS users of Mullvad VPN or other VPN services. The problems require fixes at the Android OS level by Google.

View quoted note →

↑ Parent

Replies (4)

Rand 1 year ago

network connection failed

Rand 1 year ago

network is still a toy; no serious discussion reccomended

Rand 1 year ago

player

final [GrapheneOS] 📱👁️‍🗨️ 1 year ago

I posted this note a while back, and we disagree with Mullvad on this. A GrapheneOS user discovered them and we are aware of some leaks they didn't mention... VPN apps can leak if not implemented properly, that's why not every VPN was affected by this according to their article. The second issue with leak while the VPN has crashed is likely an OS bug (race condition?) though and what we want to fix. Fortunately this affecting someone should be a very low chance and bo one would go out of their way to reproduce this bug willingly by forcibly disconnecting and timing a DNS query at a precise moment.

final [GrapheneOS] 📱👁️‍🗨️

They would have, but we have heavy disagreements with Mullvad on how they phrase this as they fixed it within their app. If it is possible to set up apps in a way that they don't leak without OS changes then it was an app issue, it's premature to blame the OS. They are being unclear about this. The Android OS VPN implementation is unaffected. The OS could also prevent these leaks but it is possible they may not had viewed this in scope of the feature. DNS is handled in a special way and the VPN gets to set DNS separately from the VPN and can send it through it or outside it, etc. VPN app developers should also be testing these basic cases themselves already ("only affect certain apps") and it appears they had not. As for the second case ("For a short period of time while a VPN app is re-configuring the tunnel or is being force-stopped/crashes"), this is being investigated. It sounds like an OS bug but a leak is not inherently responsible by the OS. Fortunately that second example is very limited. It is also worth noting they did not discover these issues first rather they were reported to us by a GrapheneOS user which we posted about days before them. We are also aware of a local network multicast leak which is an actual OS bug which they haven't mentioned. Also see: https://news.ycombinator.com/item?id=40252719 Mullvad are also linking an older article regarding a connectivity check "leak" which is misleading. That connectivity check is needed for determining which networks work, and triggering captive portals the user can interact with to log into WiFi networks with login pages. This would help you deal with the captive portal *without* disabling the VPN which would make everything else leak. GrapheneOS has also had the option to disable or change it for a long time.

View quoted note →

1 replies ↓