“With a VPN, you’re invisible on the internet.” “Without a VPN, your login credentials aren’t protected!”
— every YouTube ad since 2019
The VPN has become the default security reflex, sold as a universal shield. The reality is more nuanced. A VPN protects network segments, not an entire path, and its usefulness depends entirely on the adversary you’re trying to keep out. This article describes the technology, then weighs the common claims against a threat model.
In short. A VPN encrypts traffic between your device and the VPN server, nothing beyond that. On a modern public Wi-Fi, HTTPS already protects the content, so a VPN mostly serves to hide metadata and to counter an active attacker on the local network. It does not anonymise you; it simply shifts your trust to the VPN provider. No technology — not VPN, not Tor, not a mixnet — offers absolute protection. The right question isn’t “am I protected” but “against which adversary, located where”. Define your threat model before choosing a tool.
What is a VPN?
A VPN (Virtual Private Network) is a system that establishes an encrypted tunnel between a device and a remote server, through which all of the device’s network traffic flows. Provided it is correctly implemented and configured, whatever passes through that tunnel is protected. An attacker intercepting it in transit between the client and the server could not read it, because everything inside is encrypted.
Enterprise use
This technology is widely used in companies, particularly for remote work. The employee uses a VPN application on their computer or smartphone to connect to the company’s internal network and thereby access the various tools and services they need that wouldn’t be directly reachable from the Internet.
Consumer use
In recent years, the VPN has captured an enormous share of the consumer market. Its use, however, is different:
- Protection on public Wi-Fi networks.
- Bypassing the geo-restrictions of streaming platforms.
- Bypassing censorship in some authoritarian countries.
- Protecting privacy and reducing the exposure of certain data. Use in a journalistic context.
Separating fact from marketing
The anonymity myth
A VPN does not anonymise you. It shifts trust from the access provider to the VPN provider, which does see your real traffic. For stronger anonymity, there is a reference tool such as Tor.
But Tor also has weaknesses and does not guarantee total anonymity. It greatly complicates traceability without removing it. Its known limits are traffic correlation attacks, where an adversary observes both the entry and the exit of the network, malicious exit nodes that read end-to-end-unencrypted traffic, browser fingerprinting, and user-side mistakes.
Newer tools aim precisely at those weaknesses. NymVPN relies on a mixnet rather than Tor’s onion routing: it routes packets through five hops, mixes them with those of other users and adds cover traffic, which directly targets timing- and volume-correlation attacks. In theory, it therefore covers a Tor blind spot. Two caveats: its latency limits it to non-real-time uses such as messaging, and it is a recent product with a limited network. A promising avenue, not an established replacement.
The correct hierarchy is thus the following: HTTPS encrypts the content, the VPN shifts trust, Tor greatly complicates traceability but does not eliminate it. None guarantees absolute anonymity. You have to reason in degrees of exposure, not in all-or-nothing.
Trust never disappears, it moves
The notion of trust is essential. You never remove it; you choose who to grant it to: the access provider, the VPN provider, or the Tor nodes. The real question isn’t “am I protected” but “who have I decided to trust, and do they deserve it against my adversary”.
Is a VPN really essential on public Wi-Fi?
Since HTTPS became widespread, the content of a large share of exchanges is already encrypted. Your banking credentials or your Facebook password are protected by TLS, even on public Wi-Fi. The VPN only adds protection over metadata and the rare flows still in cleartext. Adding a DoH configuration can be relevant, since DNS queries remain in cleartext by default, hence observable and forgeable.
Choosing based on your threat model
The three questions to ask
Any security recommendation stated without a defined adversary is hollow. Before choosing a tool, it is essential to ask these three questions: what are you protecting, against whom, at what cost. The threat model precedes the choice of technology.
One question, several answers
The table below pits adversaries against technologies. Read it with the caveat that follows, because it simplifies.
| Adversary | HTTPS only | DoH | VPN | Tor |
|---|---|---|---|---|
| Active snoop on the Wi-Fi (MITM, evil twin) | Content protected, DNS and metadata exposed | DNS also protected, SNI/IP exposed | Sees only a tunnel | Sees only a tunnel |
| Wi-Fi access provider | Content protected, sees DNS, SNI, IP | DNS removed, sees SNI, IP | Sees only a tunnel | Sees only a tunnel |
| Actor in transit | Content protected, metadata variable | DNS protected | Sees only a tunnel up to the VPN server | Sees only a tunnel |
| ISP | Sees all the metadata | DNS removed, sees SNI, IP | Visibility shifted to the VPN provider | Traceability heavily complicated |
| Government | Sees metadata, can compel the actors | Same, can compel the resolver | Can compel the VPN provider | Complicated, correlation possible |
On the first three rows, the VPN settles it cleanly. On the last two, it removes nothing; it shifts the trust.
All of these protections assume a healthy device. A malicious root certificate already installed on the machine breaks TLS, and therefore everything that depends on it: an attacker can then intercept the encrypted traffic, and even the connection to the VPN server depending on the protocol used. None of these tools protects an already-compromised device.
The adversary’s position
This table hides an important nuance: these technologies do not protect a path, they protect segments. A VPN encrypts only the leg between the device and the VPN server. Two break points remain.
The VPN server itself. If it is compromised or malicious, it sees everything the encryption hid from the local network. You have given it exactly the surveillance position you denied to the public Wi-Fi.
The segment after the VPN server. Between the tunnel’s exit and the destination, the VPN is no longer of any use. Only HTTPS still protects. An adversary placed there, or on the destination server, sees the traffic as if the VPN didn’t exist.
Real security is that of the weakest link along the whole journey. The question “Am I protected” is badly framed. It should be rephrased as “on which segment, against which adversary placed where”. And “sees only a tunnel”, in the table, does not mean the adversary is powerless: they remain blind to the content and the destination, but retain volume and timing analysis.
Conclusion
None of these technologies is a universal shield. HTTPS, DoH, VPN and Tor each protect a precise perimeter against an adversary located in a precise place. The right reflex isn’t to stack protections, but first to define your threat model, then to choose the tool that covers the segment and the adversary that actually matter.
Sources
- RFC 8484 — DNS Queries over HTTPS (DoH), 2018. https://www.rfc-editor.org/rfc/rfc8484
- RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3 (TLS, SNI), 2018. https://www.rfc-editor.org/rfc/rfc8446
- Tor Project — What attacks remain against onion routing? (traffic correlation, exit nodes, threat model). https://support.torproject.org/about-tor/security/attacks-on-onion-routing/
- Nym — mixnet architecture documentation. https://nym.com/docs/network
