Indeed, the author is confusing things here:

- It has a vastly smaller attack surface than e.g. OpenVPN, because it is much less complex.

- Its performance is improved by being kernel based.

- Compatibility is helped by it being in the mainline kernel, i.e. every device shipping a recent enough kernel will be able to have it (no need to deploy/version libraries etc).

These don't have anything to do with each other.

re smaller surface area, adding some numbers, "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." https://arstechnica.com/gadgets/2018/08/wireguard-vpn-review...

note openvpn sans openssl is 70k (supports multiple crypto libs), but given Wireguard's code size is including crypto, it seems apt to compare totals.

linus on a comparison, "Can I just once again state my love for it 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." https://lwn.net/Articles/761939/

> ...compared to the horrors that are OpenVPN and IPSec, it's a work of art.

https://wireguard.com/ should put that quote up as a, well, social proof.

WireGuard’s protocol was also formally verified by a third party [0]. That makes me more confident in using it than any social proof whatsoever :)

[0] https://prosecco.gforge.inria.fr/personal/bblanche/cryptover...

ZeroTier's core is only about 30k lines of code including quite a lot of verbose multi-line comments, crypto, C++ cruft, and boilerplate. Core functional code implementing ZT is probably roughly 2X the size of Wireguard. How in the hell is IPSec that big?

It's bigger if you include all the service and virtual net device and UI stuff, but IPSec doesn't include any of that so comparing to the ZT core is apples to apples.

How is ZeroTier on dynamic allocation? Small code size is one WireGuard software security goal; minimizing dynamic allocation is the other.

It does dynamically allocate, though it always checks for success. It could be refactored not to but so far we haven't targeted devices small enough to worry about a megabyte or two of RAM. There are also checks in place to guard against memory exhaustion attacks where applicable.

We just did phase I of a professional audit for V2. It was a design audit, but we're doing a code audit too. V2's code base will be a bit cleaner.

Cool! Just a thing to think about! Code size is a useful metric, especially as it improves auditability. But not having to think about object lifecycle bugs ("can this timer fire into a freed connection state block", etc) is a huge intrinsic structural win. Having an unusually clear, audited documentation of the lifecycles of all the objects in your design would also go a long way.

I was trying out ZeroTier a few years back and found it fantastic. I was, at the time, working for a large security network device provider and trying to get R&D to bake it into the flagship product - this was before SD-WAN really took off. I never got anywhere with that agenda, but - still think that would have been a fantastic use case.

I'm curious if the stalwarts of the network security space, with their old and crusty VPN concentrators, finally move on WireGuard. Likely not until enough customers move away from them to a solution using, or they get around to finally running a recent kernel.

Crusty stalwart here. I'd love to get off crusty VPN concentrators. I'd personally love to see something in the open source space that supports 2FA and a rich, user-based policy language. Tailscale is trying to deliver an enterprise product that builds this on top of Wireguard. I'm not aware of any open source approaches tackling this problem like Tailscale, but I'm keenly interested.

Curious if you can provide any links to exactly what you need. 2FA is obvious but what kinds of policy languages are you thinking of? There are numerous variations out there.

Look up Appgate sdp

Wireguard is 6k lines if you don't count tools, crypto code, tests, etc. And god knows what is counted in those 600k lines of OpenSSL+OpenVPN, probably all kind of code that's not really used at all by OpenVPN.

It's still smaller, but no need to do useless comparisons.

But these are related, aren't they? Not trying to be pedantic or argumentative at all, just better understanding (for myself at least). Being kernel based means it cannot depend on external/3rd party libraries, which does reduce the attack surface. Of course user-land library can also be written with no other library dependencies, but I think kernel based forces this as a requirement, doesn't it (I don't know for sure, please correct me if I'm wrong)?

Moving something from userland to the kernel is not generally understood to be attack-surface-minimizing. One of the goals of attack-surface-minimizing designs, like privilege separation, are to get as much out of the kernel (or out of privileged processes) as possible.

Hosting WireGuard in-kernel is a performance and compatibility strategy. Being hosted in kernel makes WireGuard higher-risk, which Jason mitigates with other software security tactics, like a simple design that can be implemented without dynamic allocation, and a tiny codebase.

Thanks for the explanation.

Not in this case; what you're talking about here is putting more apertures into the keep.

> Being kernel based means it cannot depend on external/3rd party libraries, which does reduce the attack surface

You are conflating two independent things. An external library could be very secure or not. Same for implementing the same function internally.

My point that you quote is about dependencies. If A depends on B, they are not independent, by definition.

Ipsec is in-kernel. I don't know if it's offloading some work into user space, though.

Thank you for clarifying the differences in a more understandable way. The bullet points in the post have been made more clear now.

This goes both ways. Userland systems are susceptible to a myriad of attacks that a kernel, being privileged code, is not. We rely on the kernel (plus CPU rings) for most of the security enforcement in a machine, after all.

However, IF that code is compromised, the consequences are much more catastrophic.

That sounds interesting.

Can you elaborate on which attacks userland system are susceptible to that a kernel is not?

A userland process can view/edit the memory of another userland process. Not so with kernel processes.

Viewing/editing of another userland process is usually done using ptrace(2). Yama Linux security module prevents that unless you are root to disable it. It is active by default on Ubuntu.

Also reading /proc/nnnn/mem does not work even for your own processes and even though file node protections seem to allow it, not sure where that security enhancement comes from.

I have been a bit weary of the WireGuard hype for much the same reason. Surely kernel mode is (a) the equivalent of running as root (b) opens up greater attack surface by virtue of running at kernel level

I have only experimented a bit with WireGuard because I wanted to avoid OpenVPN. The argument seems to be that it's more secure because it's implementation is small (the implication being that it's easier to audit) and being in the kernel ensures mass adoption (ensuring even more likelihood of audits and quick patches.) I'm interested if there are other technical advantages for specific threat models.