Perhaps curiously, she advocated users of public Wi-Fi should “install a reputable virtual private network (VPN) on your devices to encrypt and secure your data when using the internet.”
Well, depends. If the user go to a captive portal to “authenticate” before the VPN could closes, than no. But, if the VPN can “pierce” through it (without any intervention from the AP), than yes. Anyways, If the user is willing to provide authentication data (like social media accounts, etc), nothing matters.
This would only be an interim solution. The attacker here sets up a fake github.com and collects credentials. So, VPN would be first trying to route over some internal hostname/IP address and probably just fail.
However, if everyone uses some VPN, the attacker can start imitating the VPN server. Or all the common ones. Redirect all traffic to a fake myvpnname.com/login with a message “you’re using your device from a suspicious location, please confirm your credentials”. You’re on a plane, so you think this makes sense, punch in your password and it’s gone!
With a VPN, the only real attack vector here is to block the VPN traffic and hope the user disables it or doesn’t notice it didn’t connect. No modern VPN will handshake with a spoofed server so it will just never connect. In some cases, the connection might fail silently enough to fool someone like this, but basically every mainstream app these days is pretty vocal about that for exactly this reason. As of Android 13, the default behavior is never to pass traffic outside the VPN unless the user explicitly turns it off. On other platforms this is dependent on the specific app.
Use a VPN mitigates this doesn’t it?
From the article:
Though I’m not sure why “curiously”.
Well, depends. If the user go to a captive portal to “authenticate” before the VPN could closes, than no. But, if the VPN can “pierce” through it (without any intervention from the AP), than yes. Anyways, If the user is willing to provide authentication data (like social media accounts, etc), nothing matters.
This would only be an interim solution. The attacker here sets up a fake github.com and collects credentials. So, VPN would be first trying to route over some internal hostname/IP address and probably just fail.
However, if everyone uses some VPN, the attacker can start imitating the VPN server. Or all the common ones. Redirect all traffic to a fake myvpnname.com/login with a message “you’re using your device from a suspicious location, please confirm your credentials”. You’re on a plane, so you think this makes sense, punch in your password and it’s gone!
With a VPN, the only real attack vector here is to block the VPN traffic and hope the user disables it or doesn’t notice it didn’t connect. No modern VPN will handshake with a spoofed server so it will just never connect. In some cases, the connection might fail silently enough to fool someone like this, but basically every mainstream app these days is pretty vocal about that for exactly this reason. As of Android 13, the default behavior is never to pass traffic outside the VPN unless the user explicitly turns it off. On other platforms this is dependent on the specific app.