WireGuard, on the contrary, is around 4000 lines of core code. This is super short, and allows for a single individual to audit it. By focusing on simplicity and ease-of-auditability, I hope to achieve something that can be considered secure.
Compare this to the massive codebase of OpenVPN/OpenSSL and the various other userspace (read: slow as mollasses) VPNs. WireGuard is considerably shorter and simpler than those too.
Also, keep in mind that on Linux, jumping from userspace to ring0 execution isn't exactly difficult. So in practice I'm not sure it matters.
I make a living by exploiting kernels. This makes me very aware of the questions associated with running this in the kernel. I've tried to write WireGuard using my experience breaking similar codebases; WireGuard is short enough that it should receive the thorough attention that this sort of software deserves. By focusing on simplicity, I think we can in time achieve something quite trustworthy.
Finally, there will be a (necessarily lower speed) cross platform implementation released that's written in Rust. At the end of the day I suspect that all parties will find themselves pleased.
This is simply not true [1] [2].
[1] - http://dpdk.org/
[1] - http://dpdk.org/doc/guides-16.04/prog_guide/kernel_nic_inter...
For a VPN that intends end-user device deployment it's kind of silly to require specific hardware.
https://lists.zx2c4.com/mailman/listinfo/wireguard
And if you're savvy and want to get involved with development, we need all the help we can find!
edit: Just read a little bit of its source, apparently you have to disable std, and he replaces it with his own linux_std that at this point has only printf implemented. So yeah it'd be a pretty intense project if one would attempt it :)
(disabling std is standard in environments like this; and you still get libcore, which is a lot of stuff!)
I know and I don't much care to see this crappy tradition carried on with this new protocol. :(
Since we appear to be bolted to the top of the thread, I'll repeat a point I buried deeper in the thread:
Maybe some readers of this thread are in the habit of casually bringing up random VPN connections between individual Linux machines. But in my experience, people tend to invest in VPN configurations so they can connect developers and ops to deployment environments and company networks. That's like, the big use case for serious VPNs.
In a serious VPN deployment, if you lose code execution on the VPN server, whether the attacker took the kernel or just a userland process is somewhat far down the list of concerns you have to deal with. A better first concern is "how many machines inside the VPN did the attacker just get code execution on because they can now make direct TCP connections to all our internal services".
From that vantage point, I'm a little less concerned about whether my VPN server is at CPL0, and a lot more concerned with things like "how complex is this code and how straightforward is it to audit".
Rather, I expect what the parent wanted to assert was that a novel malformed packet to a badly written VPN shouldn't bring down the entire VPN gateway machine, but rather just the VPN daemon itself, which can then be brought back up by init(8).
Or, to put it another way—even though the Linux kernel is monolithic, it can still pay to treat it as a microkernel and isolate fault-prone code outside of it.
This was one of the original big benefits of running e.g. the NTFS-3G in FUSE, when that support was experimental: the NTFS-3G driver did crash—often!—and your OS stayed up. The—usually external—drive would just get unmounted, and have to be fsck(8)ed.
Now, the argument you used also kind of answers this: in full deployments, we've got dedicated VPN gateways on either side of the connection, so if the VPN process crashes, the whole machine may as well have crashed, since it's not doing much of anything else anyway.
That's probably true for most networks, but I could think of one exception: a VPN gateway serving multiple customer sites. You'd really rather that one VPN "receiver" process crash on that host (like one webserver instance serving one request) than that the whole machine crash.
> But in my experience, people tend to invest in VPN configurations so they can connect developers and ops to deployment environments and company networks. That's like, the big use case for serious VPNs.
You're missing the other big use case: VPNs used to get one's internet access through a different network, in order to evade the Great Firewall, limit NSA surveillance, increase security on public Wi-Fi networks, or just watch Netflix in the 'wrong' country. These are often commercial (not that commercial VPNs are going to use WireGuard as long as it's Linux only, but hopefully it'll be ported to other OSes before long). In this case there are two ways the client could be attacked: the network itself could be modifying packets or doing a MitM attack, or the server could be hostile (either after being hacked itself [maybe with the same exploit] or, mostly applicable to government attacks, because it was set up as a honeypot).
With a network attack, the VPN code is one of the only bits of attack surface available to the attacker, especially if they don't know your IP on the other end. A hostile VPN server you route all internet access through, in comparison, already has quite a lot of power over you (hopefully you access all important services over TLS), and at the very least makes it easy to deliver (easier-to-find) browser exploits - but in theory the VPN implementation provides some additional attack surface which bypasses all sandboxes. Also, paranoid users may have a setup where their browsing is done inside a VM, whose connection is routed through a VPN on the host end. This helps ensure that they're not accidentally passing traffic through the wrong interface or leaking their real IP, and provides some protection against attackers who get code execution with the goal of finding said IP (see FBI Tor malware). In such a setup, any networking code running outside the VM is an interesting target.
Linux isn't all that secure against unsandboxed user processes, but VPN code has a simple enough interface that it could in theory be sandboxed effectively using seccomp-bpf.
The Great Firewall tries to block VPNs anyway, so a Chinese attack isn't all that realistic as things stand, but who knows, it might be nice if WireGuard grew some kind of obfuscation support. And that leaves the NSA and others.
Anyway, I don't actually think there's a problem with WireGuard living in the kernel! - because I don't think it presents much attack surface. It's a very small codebase, and performance is important for these applications. Actually, I wholeheartedly approve of WireGuard: it seems like a really nice design, and I've experienced the pain of just getting other VPN implementations to work, never mind securely. But if there is a vulnerability in WireGuard, then for the reasons I've stated, I think its placement in the kernel matters.
I doubt WG is a real candidate for the case you're talking about.
Web proxies are suboptimal because they only work with web traffic, or even if you use HTTP CONNECT, only TCP. SOCKS is mildly better at a protocol level, with SOCKS5 supporting both TCP and UDP, but still suboptimal if the server end is able to give each client its own IP address (not so common with IPv4 but easy with IPv6), due to the existence of protocols other than TCP and UDP. More importantly in practice, SOCKS clients are typically implemented in userland rather than the kernel, so each individual application needs to be configured to use the tunnel. There is software that lets you use any program with SOCKS by hooking socket API calls, but that's essentially a hack, and has many practical issues. Much nicer to just have the tunnel as a network interface like any other, and let the kernel's network stack work as it was designed - which is usually done with VPN software. VPN also lets one host transparently handle proxying for another, e.g. a router for a home network, or the host in the VM setup I mentioned in my original post.
You're talking about two completely different use cases with very different goals and potential issues.
You mean like lvs/ipvs? [0]
> How about some TLS termination?
You mean like the KTLS project from Dave Watson/Facebook Engineering? [1][2]
[0] http://www.linuxvirtualserver.org/software/index.html
The less irrelevant code you have around in a security box, the better. The attack surface shrinks.