Here at Security Forge we like to experiment with exciting new technologies, today we’re going to talk about a new VPN that is revolutionizing the field of Virtual Private Networking.
This technology can be used to modernize your infrastructure or apply a strong security model where before couldn’t have been possible or imaginable.
WireGuard® is a free and open-source VPN connection protocol created in 2016 by Jason A. Donenfeld to be faster, simpler and more lightweight than other protocols.
The good old OpenVPN runs on 600k lines of code; IPsec, another standard secure communication protocol is 400k lines of code long, Wireguard is only 4k. That’s less than 1% of the other monstrous alternatives.
Being smaller is good, makes it easier to manage, debug and validate the code. Besides that, having such a small attack surface dramatically simplifies audits. Infact, it has been analysed in all sorts of formal verification procedures.
This is the typical case where writing something from scratch makes everything simpler and better.
WireGuard is cryptographically sound, it only uses carefully selected state of the art cryptography that are both secure and extremely fast, such as the Noise protocol framework, Curve25519, ChaCha20, Poly1305, BLAKE2, SipHash24, HKDF, and secure trusted constructions. Combining high-speed cryptographic primitives with the fact that WireGuard lives as a module inside the Linux kernel, means that secure networking can be run also at very high-speed.
This makes Wireguard suitable for small embedded devices or any fully loaded routers, or even for your phone.
A bright future ahead
The future of becoming a widely adopted standard is very promising: it was included in the mainline kernel module in 2020, but before that it was adopted by many commercial VPN providers and has now multiple implementations that work on different platforms. WireGuard is well defined and thoroughly considered, it is described in its technical whitepaper, an academic research paper which clearly defines the protocol and considerations that went into each decision.
As any secure protocol the initial handshake establishes symmetric keys used for data transfer, this represents a state that needs to be kept by both ends. This handshake occurs periodically, in order to rotate keys and for guaranteeing perfect forward secrecy.
There is a clever mechanism that ensures that the latest keys and handshakes are up to date, renegotiating when needed and avoiding negative effects of packet loss.
When you bring the connection up, everything else is handled for you automatically. so, you don’t need to worry about reconnecting or reinitializing anything.
WireGuard has built-in full IP roaming on both ends.
Both client and server send encrypted data to the most recent IP endpoint for which they successfully decrypted data.
The client configuration contains an initial endpoint of the server, so that it knows where to send encrypted data. The server configuration doesn’t have any initial endpoints of the clients because it is able to discover it by examining from where correctly authenticated data originates.
If the server itself changes its own endpoint, and sends data to clients, they will discover the new server endpoint and update their configuration to be just the same.
Ready for Containers
WireGuard sends and receives encrypted packets using the network namespace in which the WireGuard interface was originally created. This means that you can create the WireGuard interface in your main network namespace, which has access to the Internet, and then move it into a network namespace belonging to a Docker container as that container’s only interface. This ensures that the only possible way that container is able to access the network is through the secure encrypted tunnel.
WireGuard avoids a denial of service because of the requirement of authentication in the first handshake message. The server does not even respond at all to an unauthorized client, it is silent and invisible.
This, however, introduces the issue of a replay attack that is solved by adding a timestamp to the initial handshake message in order to ignore too old messages.
— next week part 2…