VPNs used to be a conservative, corporate cybersecurity choice pitched as a way of improving control and compliance.
These days, however, VPN ads are everywhere, aggressively pitching VPNs as a must-have consumer product for breaking free of unwanted controls and steering clear of snooping and surveillance.
Quite a double-edged sword!
How do VPNs really work, and what purposes do they really serve?
The VPN dilemma
You’ve almost certainly come across the magic cybersecurity letters VPN, short for virtual private network, most likely in a deluge of online ads from vendors that just happen to sell VPNs, warning you never to go online without one.
More precisely, of course, they tell you never to go online without their VPN, but that’s a detail of marketing we’ll ignore in this article.
But you’ve probably also seen online ads and press releases from big cybersecurity vendors telling you that VPNs are old-fashioned and inadequate, and that you’d better switch to something called zero trust instead, which sounds like yet another cybersecurity component you need to buy, and deploy, and manage.
If you’re confused, you’re not alone, especially if you’ve also seen ads from more aggressive VPN companies implying that their VPN will give you such a dramatic and immediate boost in online security that you can give up using any other cybersecurity products.
In this two-part series, we’ll be digging into the history of VPNs, their operation, their risks and benefits, and how they tie into the broader face of both cybersecurity and cybercrime.
We’re not going to cover zero trust in any detail here; we’ll just point out that the phrase ‘zero trust’ is a general one that doesn’t really refer to any specific technology or product.
Zero trust is a self-descriptive jargon term for an approach to network security that avoids assuming that users and devices are secure today just because you assumed they were secure yesterday.
It doesn’t literally mean that you never trust anyone, ever; instead, it means that you avoid trusting people or devices indefinitely or automatically.
By regularly and frequently verifying computers, users, and software to ensure that they are still working within the security limits you expect, you can reduce the risk of a security blunder that goes unnoticed until your whole network gets compromised.
In contrast, a VPN is a specific technology, or perhaps a portfolio of protocols, for interlinking two physically separated devices or networks over someone else’s network, thus joining them together virtually instead of connecting them directly with a physical cable or a point-to-point wireless link.
This can help you to turn a bunch of otherwise separate local area network (LAN) ‘islands’, including small branch offices and home offices, into a well-ordered wide area network (WAN) that can be configured, managed and used almost as conveniently as a single LAN at a single site.
Non-virtual private networks
In the early days of networking, before commercial companies could easily get access to the internet, interconnecting two buildings or two campuses that weren’t on the same private property was typically achieved using so-called leased lines, or private network circuits.
In this context, the term ‘private network circuit’ didn’t refer to something that you owned and operated yourself, but to a connection, reserved solely for you, acquired from a public utility company.
This sort of link was needed because privately-owned data connections that traversed public property, even just to reach a building on the other side of a public road, were illegal in many countries.
The only way to get connected under those circumstances was to lease for your exclusive use what was essentially an always-on connection from the telephone company.
Data security and authentication on leased-line links were often ignored, for three main reasons.
Firstly, even though the ‘private’ wiring wasn’t yours, it wasn’t easily accessible to other people, because it was owned and operated by the telephone company, and each end of the physical link terminated inside your private property.
Secondly, encryption on the link required extra, expensive hardware devices at each end, and the link itself was probably expensive enough already, not least because many countries operated strict telecommunications monopolies that made competitive pricing impossible.
Thirdly, the LANs at each end of the leased-line link generally weren’t encrypted anyway: they were considered ‘non-public’ and therefore safe to use without encryption, so why worry about the non-public wiring between them, even though the phone company owned it?
Why not go virtual?
Once internet access became widely available to commercial companies and individuals, however, the obvious money-saving question was, “Do we still need expensive leased lines between our LAN islands?”
What if computers on two different private networks could simulate each end of a leased-line circuit, so that the networks would still appear to be connected privately and directly, even though the data was travelling over the public internet?
Even better, what if any individual computer, for example a remote user with a personal computer at home or a company laptop on the road, could simulate the other end of a leased line using software alone?
That way, instead of dialling a dedicated remote-access modem back at head office, typically at an exorbitant cost, remote users could connect locally to to the internet, perhaps for just pennies a minute, and then use their leased-line ‘simulation software’ to set up what would be a virtual private network connection into the company network.
This VPN connection would essentially be a ‘network teleportation tunnel’ that provided the remote user with the convenient illusion that they were plugged directly into the LAN at work.
Indeed, the user would end up with an IP number and a network name just like the one they’d have at work, and be visible on the LAN to colleagues and sysadmins, whether those fellow workers were in the office and directly on the LAN, or themselves hooked up over their own VPN connections.
The company would save a fortune in dialup costs, and users wouldn’t need to keep dialing and redialing until a modem become available at head office.
At the same time, the VPN software at each end could not only require users to authenticate with a company password, thus providing access control, but also encrypt all the virtual network traffic to inhibit snooping and tampering on the public internet.
In theory, at least, software-based point-to-point encryption could make a cheap VPN connection more secure than an expensive leased line.
Leased lines were relatively secure from snooping, thanks to physical security measures at the telephone company.
But they weren’t absolutely secure, given that the phone company itself had access to all the wires carrying all the data for all its users at all times, and because the wiring to many customer sites passed through one or more insecure cabinets on public streets along the way.
PPTP and beyond
The first widely-used VPN software of this sort was PPTP, or point-to-point tunnelling protocol, which was built into early versions of Windows, and emerged in the late 1990s from an industry consortium led by Microsoft.
Intriguingly, PPTP was not itself a complete VPN protocol, but merely a way of ‘tunnelling’ data packets using a much older system known as PPP, or point-to-point protocol, which was a way of simulating an internet-style network connection over a serial link or a dial-up connection, and was itself an enhancement of an even earlier protocol with the self-explanatory name serial line internet protocol, or SLIP.
PPTP therefore provided a handy way to set up the network-style exchange of data packets between two computers in such a way that the internet hops between the two devices were effectively invisible to each end of the link, which could therefore consider itself directly wired up to the other end.
Authentication and encryption weren’t part of PPTP itself, but were agreed upon at each end of the link; Microsoft’s implementation used two cryptographic systems: MS-CHAP and MPPE, where the letter MS and M in those abbreviations stood for Microsoft.
CHAP, the challenge-handshake authentication protocol, was based on 56-bit DES encryption, which was already considered weak by the mid-1990s, and was disavowed and officially replaced with 128-bit (or more) AES encryption in 2001 by the US standards agency.
PPE, meaning simply point-to-point encryption, was based on an encryption algorithm called RC4 that was known to have serious algorithmic flaws by the mid-1990s, and was considered cryptographically broken and unrecoverably unsafe to use as early as 2001.
PPTP, together with MS-CHAP and MPPE, are no longer recommended, and many service providers no longer support them because the security they provide is inadequate, so make sure to avoid them. (You can argue, in fact, that by giving a false sense of security they are actually worse than inadequate, effectively delivering ‘negative security’.)
Other VPN protocols and systems you are likely to encounter include:
- L2TP IPSec: Layer 2 Tunneling Protocol with IPsec (IP Security).
- IKEv2: Internet Key Exchange version 2 with IPsec.
- SSTP: Secure Socket Tunneling Protocol.
- OpenVPN: An open-source toolkit with its own protocol.
- WireGuard: Another open-source toolkit, initially released for the Linux kernel but now available on Windows, macOS, mobile phones and more.
Many cybersecurity vendors include VPN functionality in their firewall products, often supporting one or more of the above protocols or something similar under a brand name of their own.
Location teleportation
As you can probably imagine, trying to trace traffic from your own computer to a remote server via a VPN gives curious-looking results.
For example, here’s a (simplified and truncated) list of the network hops that data took from my own network to three different final destinations.
Firstly, here’s a partial list of the internet path from me, via my local coffee shop, directly to example.com, which had the IP number 93.184.215.14 at the time of my test:
Secondly, here’s the internet path from me to a VPN server named demo.wireguard.com, a handy test system for troubleshooting that is provided for free by the creator of the WireGuard VPN source code:
The first few hops, unsurprisingly, follow the same network path as the example.com trace (both shaded pink), before diverging to reach their different logical and physical destinations in the United States.
But with my computer configured with a VPN client set up to ‘teleport’ via the demo.wireguard.com server, the route to example.com changes dramatically:
To be clear, the low-level data packets exchanged between the VPN client on my laptop and the VPN server in order to create this virtual LAN connection almost certainly followed the same route as the hop-tracing traffic seen above (shaded pink and grey), but you can’t tell this from the new trace.
My traffic appears on the public internet for the first time in the US, not in the UK, although it then follows a similar path to the last part of my original connection to example.com (shaded blue).
The entire network path from my laptop to the VPN server in the first place (pink and grey) has magically been eliminated from the trace.
Hiding in plain sight
When a company runs a VPN server for its staff to access corporate assets, even if those assets are in the cloud rather than on the company network, those users appear to be part of the LAN, which can be a big advantage for management and control.
Notably, when VPN-connected users then accesses the internet, for example to login to the corporate blog server or to access the cloud-based HR system, their web traffic really does emerge from the company network, not from a coffee shop or their home LAN.
Their usage can thus be subjected to the same filtering rules, zero-trust verification and other security controls as everyone else in the company, whether they’re working remotely or not.
But VPNs can be also be used for almost exactly the opposite purpose, providing what you can think of as a funnel operating in reverse.
Home users, for example, don’t generally pay for a VPN service so they can voluntarily corral their traffic into a carefully-controlled LAN environment that is closely managed by someone else.
Instead, their usual goal is to emerge onto the public internet without any restrictions at all, with little or no immediate evidence (or so they hope!) of who or where they actually are.
For example, here are two runs of a simple utility that I use when I am on the road to check where on the internet I appear to be.
For the first run, I accessed the internet directly via the router on the LAN and its local ISP; for the second, I activated the WireGuard VPN and told my operating system to access the internet indirectly via the demo.wireguard.com test server:
The showmyip script sends a special UDP packet to a home server that simply extracts the so-called source IP number from the header of the incoming request and sends it back as data in a UDP reply.
(The source IP is the network address to which replies must be sent if they are to get back to the right place: a sort of ‘mandatory-signpost-back-to-the-starting-point’ that every internet packet must include.)
In the first example, the UDP request went as good as directly to my home server without leaving the UK, or even southern England, so the reply came back quickly, taking under 50 milliseconds, including the time needed for various cryptographic computations carried out by the server, which is a modest Raspberry Pi.
The reply reveals the IP address of the router in the coffee shop where I was working in the UK, which is where my laptop’s network traffic first reached the open internet.
In the second example, however, I was hooked up via the WireGuard VPN test server we saw in the traffic routing lists above, so the IP address reflects the location of the VPN server in the US, not of the the LAN I was actually connected to.
Impossible travel
In just four minutes (based on the timestamps 12:22:01 and 12:26:07 in the screenshots above), I apparently rocketed both myself and my laptop from the gentle Oxfordshire countryside, more than an hour away from the closest international airport, all the way to upstate New York, somewhere near Lake Erie.
Abruptly, I stopped being one of a few possible users on a genuinely local area network in England, and turned into one amongst potentially millions of concurrent users of the same VPN, who all appeared to be in the same part of the Northeastern US but almost certainly weren’t.
This sort of pseudoanonymity and location hiding is exactly the outcome that popular VPN services pitch to consumers as a cybersecurity benefit.
Why give away that you are at home, and where that home is, when you can legally and conveniently give the impression of being in Canada, Cape Town, Canberra or California instead?
Why not disguise your location to thwart the often intrusive tracking and targeting that modern websites love to carry out?
Better yet, what if the VPN provider lets you change your imaginary location as you go along?
That way, you will not only have the pseudoanonymity you were promised, but also be able to navigate your way around the ‘regional content blocks’ that many online services enforce.
These often happen either for commercial reasons, for example because the service hasn’t licensed that content for use in your part of the world, or for legal compliance, perhaps because your government has censored it and made it illegal to serve up to visitors from your country.
Want to watch BBC TV programmes outside the UK, or to read US online news that is suppressed in Europe because it doesn’t have cookie warnings, or to access foreign-language websites in their native language without having them switch automatically to English?
A typical consumer VPN service will let you do all those things, and more.
How safe is a VPN?
But just how safe and solid is the pseudoanonymity that these non-corporate VPN services promise?
Can they really replace existing cybersecurity products you are using, thus saving you both time and money?
And if they do indeed make you as safe and as untraceable as they suggest, are they actually in the public interest, or are they just magnets for illegal activity?
On the other side of the fence, what could go wrong with a corporate VPN that’s supposed to funnel and limit your view of the internet for your own and your company’s safety?
A corporate style of VPN is supposed to avoid anonymity, enforce authentication, improve accountability, and help your IT staff keep you more secure than you would be if they left you to your own devices.
But what if the VPN creates a false sense of security, or makes it easier for cybercriminals to run amok in your network just by hijacking an existing VPN connection?
Or what if the VPN inadvertently allows your users to bypass restrictions that are supposed to apply where they live, thus leading the company into regulatory hot water?
Lastly, what about the performance implications of sending your network traffic on longer journeys than is necessary, as we saw in the sixfold slowdown in the showmyip example above?
Now read Part 2, where we compare the good and the bad of VPNs, and provide some Top Tips for using them safely and responsibly…
More About Duck
Paul Ducklin is a respected expert with more than 30 years of experience as a programmer, reverser, researcher and educator in the cybersecurity industry. Duck, as he is known, is also a globally respected writer, presenter and podcaster with an unmatched knack for explaining even the most complex technical issues in plain English. Read, learn, enjoy!
Featured image of maze by Susan Q Yin via Unsplash.
