Just FYI, WireGuard is baked right into the Linux 6.x kernel. Unless you're on a rolling distro you won't see it yet, but very cool indeed.
5.6
Getting Started with WireGuard
11–20 of 72 posts
Re: Getting Started with WireGuard
#12> It’s kernel-based which reduces attack surface and can be ran in virtually any device. Excuse my ignorance, but can someone explain why a kernel based networking stack has less of an attack surface then a user-space based stack? I mean logically user-space should be more secure no?
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.
Re: Getting Started with WireGuard
#13Hm. I guess no-one has bothered with nftables yet, even when dealing with network code that's becoming part of the new upstream kernel (not just this blog, AFAIK wireguard upstream doesn't have any examples on using nftables either, just iptables).
I guess we need a new networking how-to?
Anyone aware of some resources I might have missed?
OK, I guess the nftables wiki is the "how-to": https://wiki.nftables.org/wiki-nftables/index.php/Main_Page
Re: Getting Started with WireGuard
#14> It’s kernel-based which reduces attack surface and can be ran in virtually any device. Excuse my ignorance, but can someone explain why a kernel based networking stack has less of an attack surface then a user-space based stack? I mean logically user-space should be more secure no?
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: Getting Started with WireGuard
#15Just FYI, WireGuard is baked right into the Linux 6.x kernel. Unless you're on a rolling distro you won't see it yet, but very cool indeed.
also available in ubuntu 20.04 (universe) via the dkms/module support thats been standard for use w/ wireguard for years. wireguard also just hit 1.0 from a stable api perspective.
Re: Getting Started with WireGuard
#16> It’s kernel-based which reduces attack surface and can be ran in virtually any device. Excuse my ignorance, but can someone explain why a kernel based networking stack has less of an attack surface then a user-space based stack? I mean logically user-space should be more secure no?
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/
Re: Getting Started with WireGuard
#17> It’s kernel-based which reduces attack surface and can be ran in virtually any device. Excuse my ignorance, but can someone explain why a kernel based networking stack has less of an attack surface then a user-space based stack? I mean logically user-space should be more secure no?
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.
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)?
Re: Getting Started with WireGuard
#18Earlier quoted context omitted.
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.
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 sur…
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.
Re: Getting Started with WireGuard
#19Does wireguard have a noticeable overhead wrt data size compared to a unencrypted connection? I was thinking of setting up it on a small RPi-Like board at home, then on the laptop I carry around (when the lockdown is over). The purpose would be connecting to the Internet through the home broadband public IP which could be handy. However the laptop connects through a metered 4G connection which, although the data cap is more than reasonable, raises some concerns should the encryption require a lot more data than normal.
Re: Getting Started with WireGuard
#20Earlier quoted context omitted.
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 sur…
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 wi…
Thanks for the explanation.