rubox-ad-pcnuts

WireGuard VPN review: A new type of VPN offers serious advantages

Fewer lines of code, simpler setup, and better algorithms make a strong case.

The WireGuard interface, with a Firefox window open to netdata.

WireGuard is a new type of VPN which aims to be simpler to set up and maintain than current VPNs and to offer a higher degree of security. The software is free and open source—it’s licensed GPLv2, the same license as the Linux kernel—which is always a big plus in my book. It’s also designed to be easily portable between operating systems. All of that might lead you to ask: in a world that already has IPSEC, PPTP, L2TP, OpenVPN, and a bewildering array of proprietary SSL VPNs, do we need yet another type of VPN?

OK, but why?

I’ve seen a few new VPN designs pop up in the last few years—ZeroTier and Tinc come to mind—and each time, I’ve thought, “I should really look into that.” And then I haven’t. I use OpenVPN heavily; I’m thoroughly familiar with it, and it scratches most of my VPN-related itches pretty well.

So how did WireGuard rattle my cage hard enough to get me to actually play with it? It had something you almost never see: a positive comment about its code from none other than Linus Torvalds.

Can I just once again state my love for [WireGuard] and hope it gets merged soon? Maybe the code isn’t perfect, but I’ve skimmed it, and compared to the horrors that are OpenVPN and IPSec, it’s a work of art.
Linus Torvalds, on the Linux Kernel Mailing List

That was enough to get me to sit up and pay attention. If you think “maybe it isn’t perfect, but” is damning with faint praise, you clearly aren’t familiar with Torvalds’ acerbic writing style.
Fewer lines of code

A little more research gave me some insight into why Torvalds might have been so uncharacteristically positive. WireGuard weighs in at around 4,000 lines of code; this compares to 600,000 total lines of code for OpenVPN + OpenSSL or 400,000 total lines of code for XFRM+StrongSwan for an IPSEC VPN. Two orders of magnitude fewer lines of code mean a lot less attack surface to find flaws in.

A much smaller codebase also means code that’s more likely to work the way it’s supposed to. One of my biggest operational beefs with OpenVPN is how its tunnels can either crash or hang.

This probably won’t happen frequently enough for you to notice if you only have a few tens of clients, and most of those are manually operated by a human clicking something to connect and disconnect their tunnel as needed anyway. But if you want to manage a network with hundreds of clients, all of which should automatically manage their own always-on tunnels, it’s a big problem.

OpenVPN features ping and ping-restart configuration arguments that should take care of this for you, but they don’t. I’ve spent more of my time crafting and maintaining watchdog scripts that carefully check for, kill -9, and restart OpenVPN daemons than I like to think about. I’d love to be able to replace them with something that just works.
Simpler setup

I don’t want to sugarcoat this: VPNs aren’t simple, and WireGuard doesn’t suddenly make them a kindergarten project. With that said, it took me a few days of careful, determined, and dedicated reading, implementation, and testing before I understood OpenVPN well enough to really have any idea what I was doing. A few years later, I needed another week or two of trawling the Internet for how-tos and piecing them together in order to build a large-scale OpenVPN-based network. I spent another half-day or so reading about the latest advancements in configuration and best practices before updating my configurations for last year’s Ars Technica OpenVPN guide.

By rather sharp contrast, I created working, stable, documented configurations for a scalable, secure WireGuard network in about six hours on a Sunday afternoon. Much of this greater simplicity in setup and configuration is due to WireGuard’s deliberate, principled rejection of cryptographic agility.
Stronger algorithms

WireGuard deliberately eschews “industry standard” algorithms which have long-standing weaknesses in favor of only the latest, toughest primitives. From the WireGuard website:

ChaCha20 for symmetric encryption, authenticated with Poly1305, using RFC7539’s AEAD construction
Curve25519 for ECDH
BLAKE2s for hashing and keyed hashing, described in RFC7693
SipHash24 for hashtable keys
HKDF for key derivation, as described in RFC5869

This all looks impressive enough, but I’m no cryptographer. I was still a little concerned about WireGuard’s future security, because there’s nothing configurable about it, and its keys were considerably smaller than what I was used to. Luckily for me, publishing my first three WireGuard VPN configs on my own blog was enough to catch the attention of Jason Donenfeld, WireGuard’s author and principal developer. That gave me the chance for a little desperately-needed Q & A. (Please consider any errors in the following content mine, not Jason’s. Did I mention I’m not a cryptographer?)

 

On the left, a WireGuard key. On the right, an OpenVPN key.

As someone who doesn’t really understand cryptography but who has been using it actively for 20 years, the combination of a short key and no configuration options made me a bit nervous. With OpenVPN, I like to err on the side of caution by using a honking big key. Why can’t I do the same with WireGuard? Why am I limited to a 256-bit key with WireGuard, while OpenVPN offers me a whopping 4,096 bits? It turns out that a 4,096 bit key is kind of ridiculous.

If you have to brute-force a 256-bit key, you have 2256 total combinations to work through. If you assume that on average, you’ll uncover the solution halfway through the problem set; that still leaves you with 2255 failures before success. Now assume that you have an extremely powerful system, capable of trying 38,000,000 keys per second, and local access to the public side of the keypair. If you’re relying on brute force, it’ll take you a little more than 1.52 × 1069 seconds on average to come up with the winning key. Given that the estimated age of the universe itself is 4.32 × 1017 seconds, that’s probably sufficient.

The reason OpenVPN (and almost all VPN solutions) use such ridiculously long keys is that you don’t have to brute-force them. An actual cryptographic attack on the algorithms commonly used for VPNs (or for HTTPS connections to websites) looks a lot more like a dictionary attack than a brute-force attack; you can discount great swathes of the problem space without having to actually try them.

The tremendous key length—and in some cases, repeated executions of the same algorithm (anybody else remember DES vs 3DES?)—is basically a naive “well, do it harder then!” mitigation that attempts to confound cryptographic attacks or expand the problem set to something so ludicrously huge that, even if you can just throw away all but 0.000000001% of it, it’s still too much to bash through.

As long as the algorithms underlying WireGuard remain unbreached, a 256-bit key isn’t just “strong enough until computers get faster.” It’s strong enough that simple physics prevent a brute-force approach—at least, until quantum computing comes into play. Quantum computers are odd beasts that have very different use cases than conventional computers, but one of the things they are extremely good at is attacking asymmetric (public/private key) cryptography. We’re not capable of creating a quantum computer large enough to attack a 256 bit key yet, but it’s expected to happen eventually. If you’re sufficiently paranoid that you want future proofing against QC, you can optionally add a PSK (Pre-Shared Key) layer to WireGuard’s encryption.

Simpler handshakes

Up until now, asymmetric encryption has more-or-less always implied a principle called cryptographic agility. In a nutshell, agile crypto is crypto in which you can change out the ciphers, digests, diffie-hellmans, and glayvin willy-nilly in order to address the changing state of the industry. The SSL encryption your browser uses is an agile protocol, as are IPSEC and OpenVPN.

At first blush, this sounds like a great idea—more options! Unfortunately, all those options mean a bunch of stuff that needs to be negotiated between client and server before the tunnel is secured—which means both more stuff that can be spied on by anyone in position for a MITM attack and more things that might break in interesting ways if they’re hammered on just right.

Instead of cryptographic agility, WireGuard relies on crypto versioning. If a devastating cryptographic attack against one of WireGuard’s underlying primitives is discovered, a new WireGuard protocol will be devised as a total package. After such an update, a WireGuard client and WireGuard server would simply need to say “let’s use v2.0 instead of v1.0!” and be off to the races. (This is in contrast to a crypto agile negotiation, in which client and server must negotiate and agree on every single primitive and key length piece by piece.) Once an admin is certain all of their clients have been updated to support the new protocol, they could simply disable the 1.0 protocol at the server and be done with it.

If you show me a list of ciphers including Blowfish, AES, ChaCha, and Polybius, I don’t know just from looking at them which is the most secure, even though one of them is more than 2,000 years old. But if you give me a list containing v1.0, v2.0, v3.0, and v4.0, you can generally rely on me to pick the right one.

Faster connections

When using VPNs, my consulting agents and I get frustrated with the lengthy, querulous handshake process. They take long enough that you feel obliged to provide some kind of dialog to the end user to reassure them that something’s happening—and to convince them not to try to “use it before it’s ready” and call their sysadmin complaining of a “broken” VPN that just wasn’t done connecting yet. When you’re accustomed to that behavior, WireGuard’s connect times seem downright magical.

 

Cutting connect times down from 8+ seconds to a 10th of a second feels amazing.

 

The proof’s in the picture above: an OpenVPN connection from my Xeon E3 workstation to Linode’s cheapest VM offering takes more than eight seconds. Connecting the two via WireGuard takes barely over 100 milliseconds. This not only means faster initial connections—it means much faster re-connections when something’s gone wonky in your internet connection and your VPN has to re-establish the tunnel beneath you.

A better VPN?

These are still early days for WireGuard, but right now, it looks like it’s probably the most secure and reliable option out there. WireGuard might also be the fastest—it operates entirely in kernel space, unlike OpenVPN, which has to context-switch in and out from kernel to userspace rapidly. But I haven’t really been able to confirm that; I saw much better speedtests from WireGuard on a very starved LTE connection from my local public library, but I saw OpenVPN holding its own or even outrunning it on a much faster Wi-Fi connection at the house later.

To be fair, WireGuard’s current Android implementation is in userspace unless you’ve rooted your phone, which I haven’t. But I also didn’t see any faster throughput using WireGuard vs. OpenVPN to connect across my gigabit LAN using real Linux x86 machines. I was hoping to do a speedtest from an Odroid XU4, which has an ARM processor much like those used in smartphones. But Odroid’s stock version of the Linux desktop is mangled and doesn’t include kernel headers, which broke the installation there until I can wipe it and install Armbian.

So, WireGuard is maybe faster, almost certainly more secure, and definitely a great deal simpler and quicker to connect than traditional VPNs. It’s also very young; Donenfeld’s git repository shows an initial commit just two years ago. Platform support is still a bit of an issue; there are official ports for Linux, Android, and BSD (including OS X). An iOS app is available in the WireGuard repository, but as it isn’t in the App Store yet. It’s probably not going to do you any good unless you’re an iOS developer yourself.

And finally, the $64,000 question: what about Windows? Support for Windows isn’t here yet. It’s on the way, and it’s going to use Microsoft’s own VPN API from UWP (the Universal Windows Platform). That is exciting news. Aside from doing away with the bletcherous and buggy TAP-Win32 adapter OpenVPN uses, that means that WireGuard connections on Windows will be managed just like the hideously insecure PPTP VPNs legions of Windows users keep using for no better reason than “it looks built-in.”

The Good

  • WireGuard’s fast connection negotiations change your perception of a VPN’s convenience. It’s hard to go back to kludgy interfaces and 10- to 30-second negotiations after you’re used to no-nonsense, instant-on performance.

The Bad

  • Waiting for Windows support is going to put WireGuard out of reach for many users for another few months.

The Ugly

  • In theory, WireGuard could greatly accelerate throughput from wimpy ARM-powered devices like phones and consumer routers, but it needs to be baked right into the kernel for that to happen.

 

arstechnica.com/gadgets/2018/08/wireguard-vpn-review-fast-connections-amaze-but-windows-support-needs-to-happen/

8/26/2018

rubox-ad-pcnuts