One of the problems with computing, especially about networking, is that all protocols have been designed to do their jobs without the end users needing to know the details.

Suddenly, it can quickly seem magic and we can easily fantasize about the possibilities and risks of these technologies without either side being realistic…

This is precisely the case with VPN… After a particularly noisy advertising campaign, everyone has heard about paid VPN services and their arguments on the security they are supposed to bring to their subscribers.

This is a textbook case of white hat communication which plays on the fantasies linked to these magical technologies:

1. Create fear by insisting on all these risks of hacking because (evil) hackers,
2. Reassure by listing all these benefits that their super miracle product provides (regardless if they are imaginary or have nothing to do with the above-mentioned risks).

So, in our evangelical demystification crusade, we have chosen to address today, without going into all the technical details what VPNs really are.

And for those who follow Erin’s adventures, this is the kind of technology she will use (spoiler alert) to connect with the resistance. This is the opportunity to talk to you, here, about the more technical aspects of the thing.

A virtual card

Whatever the computer problem, and to simplify everyone’s life, resources are accessed via interfaces. You send your request to the system and it will take care of all the complex and technical details without you having to think about it. It’s opaque, and that’s good.

For the network, it’s the same thing. When a program wants to send data over the network, it puts it in a sort of envelope and hands it over to the operating system which will take care of the details. Your program does not need to know if its envelope will go via cable or Wifi, in IPv4 or IPv6, if and how the checksums are calculated. It uses an interface that hides these details.

And since these details are hidden, nothing prevents them from being simulated 😁. The system may very well provide you with a “virtual network interface”. When your programs send their envelopes (containing their data) there, they are not serialized to a peripheral but given to a program that will simulate these operations…

For example, the localhost address (127.0.0.1 in IPv4 and :: 1 in IPv6) allows programs on the same machine to communicate with each other as if they were doing so through an IP network.

Your motherboard does not of course have a mini-network card for that, it is the system that simulates it: when it receives a packet destined for this specific address, it knows that it has nothing to physically send. and will simply pass the data to the recipient program.

A virtual network

To go further, and create a virtual network, you can also connect two virtual cards on machines each at one end of the Internet.

• When a program receives data from the system, it will copy them into a new envelope for the other program.
• When a program receives the data from its opposite, it opens the envelope and supplies the data to the system which will treat them as if they came from a real network card.

For the users of this virtual network, it is as if the data have been cryogenized during the journey. They don’t see the difference between the usual situation (sent directly into the network) and the virtual network (frozen in an envelope and then thawed at the other end).

We can make an analogy with the road network for freight transport. There is no road that allows a truck to pass between two continents, so we transship temporarily onto freighters. The correspondents do not see the boat, they can tell themselves that it did not leave the trucks.

The two systems then act as if they were themselves connected to each other. You can also adhere to this computer fiction and behave as if these two machines were indeed plugged into each other.

Virtual, but private

As you would expect, in most cases, we would like no one to be able to intercept or modify our data in transit. Sending them as is on the network is therefore not the best idea of the century (especially since it is only 2021).

Not surprisingly, to protect them in the tunnel, cryptography is used. Each VPN has its little preferences, habits and conventions, so I won’t detail all the cases but in general, we will always find the same principles.

An initialization phase where the programs discuss to establish all the parameters necessary to protect the transfers of the virtual network data.

• Asymmetric algorithms to encrypt and sign these first exchanges (and therefore very often a PKI), and sometimes used to authenticate the ends,
• A key exchange algorithm that will be used for the next phase (i.e. Diffie Hellmann).

A nominal phase where the programs send each other virtual data and possibly some small signals (i.e. to keep the channel open). When this phase disconnects, it is sometimes possible to restore it directly without going through the negotiation phase (it depends on the protocols).

• A symmetric algorithm to encrypt data (often AES-128 but sometimes others of the same kind), using the key previously exchanged,
• A data integrity verification algorithm, HMAC or signature as appropriate.

With all these algorithms in place, we can then be sure of the identity of the VPN participants, that only they will know the content of the data in transit and that it could not be modified.

And after ?

Regardless of the technology used, regardless of the provider, a VPN is therefore nothing more than a new (virtual) network card through which your system is connected directly (but virtually) to a remote infrastructure. All traffic entering it is protected until it exits and then the physical world will resume its rights.