You’ve probably seen adverts for at least three VPN providers on your favourite YouTube channel. No doubt the presenter will have extolled the privacy and security virtues of their benevolent sponsor (perhaps while conflating those terms), imploring you to sign up with a bespoke discount code. Maybe you signed up a year ago, have just been stung for another year at full price, and are wondering what you’re really paying for (or if you should really trust that YouTube personality). Perhaps you sometimes have to use a VPN for work, and wonder how this relates to the consumer VPNs for which your favourite tech review site is peppered with referral links [stop mocking TechRadar; the execs will cancel us – ed].
A VPN is a proxy that routes all or some of your traffic through an encrypted tunnel, with the effect that your ISP (internet service provider) can only see that you are connecting to that VPN. It can see how much traffic is flowing, but not where that traffic’s end points are or what that traffic is (any and all protocols can be stuffed into the encrypted tunnel). Conversely, any site or resource that you access via a VPN can only see the VPN’s IP address, not the one provided to your home router by your ISP. It’s worth noting that there are proxy services that are technically distinct from VPNs. The main difference is a lack of encryption in the tunnel, which technically doesn’t matter if you’re just tunnelling web traffic from HTTPS sites. However, it’s possible that a web proxy might be set up in such a way as to forward your real IP address (for example, for WebRTC traffic that needs a direct connection), which nullifies any privacy suppositions. That said, techniques such as TunnelVision (see box) or the long-standing iOS decloaking vulnerability (www. michaelhorowitz.com/VPNs.on.iOS.are.scam.php) might also have this effect.
VPNs have been around for about as long as the web itself, but were initially only used to restrict access to corporate networks. More specifically, companies wanted to allow remote or off-site workers access to their resources, but without the risks associated with putting them on an internet-facing server. Even in the early days, people knew it was a bad idea to do this, even if that machine is protected by a password or key. Instead, a public VPN server was set up and legitimate users could authenticate with this using their usual work credentials (and possibly a certificate if access was restricted to, say, company-provided laptops). Connection would be over a protocol such as PPTP (Point-to-Point Tunnelling Protocol), IPsec (standard IP packets wrapped in encryption), L2TP or, later, OpenVPN. Then, thanks to some nifty routing tricks, the remote user could access work resources as though they were in their office cubicle. Depending on the setup, the remote machine might see all of their traffic routed through the VPN (so that it was subject to the same restrictions as in the office) or non-corporate traffic being allowed to flow unimpeded.
A grossly oversimplified view of what a VPN does. The websites pictured would be oblivious to your IP address.
TUNNELVISION
At the end of May 2024, researchers from Leviathan Security Group announced that they had discovered a vulnerability (CVE-20243661) that they called TunnelVision (see www.leviathansecurity. com/blog/tunnelvision). When exploited, it reroutes traffic outside the VPN tunnel, undoing any privacy benefits and allowing all traffic to be sniffed. What was shocking about it was that it affected Windows, iOS, Mac OS and Linux, and could potentially have been exploited since 2002. It also relied on a relatively simple trick, running a malicious DHCP server on the target’s network. This was enough to thwart all modern VPN protocols, namely OpenVPN, WireGuard and IPsec. Only Android was immune, thanks to its DHCP implementation not supporting a certain parameter.
TunnelVision can be mitigated against if your DHCP server allows you to disable this setting (called 121), but the exploit can then be used to disable network access entirely. On Linux, namespaces can be leveraged to defeat the attack, but these aren’t something your average user wants to be involved with. Naturally, an attacker already needs some sort of foothold on your network to run the malicious DHCP server, but this is a far lower bar than traditional exploits. It’s also easy to do by setting up a public Wi-Fi hotspot. Many have said the real threat has been overestimated, but it is food for thought.