Earlier this evening, Linus released Linux 5.6, which contains our first release of WireGuard. This is quite exciting. It means that kernels from here on out will have WireGuard built-in by default. And for those of you who were scared away prior by the “dOnT uSe tHiS k0de!!1!” warnings everywhere, you now have something more stable to work with. The last several weeks of 5.6 development and stabilization have been exciting, with our codebase undergoing a quick security audit, and some real headway in terms of getting into distributions.
WireGuard is probably the biggest new feature in 5.6, announced earlier today.
I’m hot and cold on this;
– If something is ubiquitous it’s inherently insecure, diversity is security.
– As discussed in an earlier related thread, IoT is where security is now really needed and this seems nowhere near light weight enough.
– If it’s IoT it’s potentially ubiquitous, firmware won’t do if it can’t be patched, eventually the ubiquity statistically breaks the security.
– If something can be patched it’s vulnerable.
And so on and so on to infinity, so stay diverse.
Standardisation breeds mediocrity.
So umm… What is WireGuard?
ronaldst
Osnews has a better explanation of it in an earlier article…
http://www.osnews.com/story/131452/wireguard-gives-linux-a-faster-more-secure-vpn/
It’s a VPN client in the kernel. I’ve really got mixed feelings about this, usually internet protocols are implemented in userspace. Selecting this one for the kernel seems kind of arbitrary to me. The author prides himself on reducing lines of code, but when you analyze the code it’s apparent that he achieved simplicity by hardcoding everything in the protocol, which can be bad for future proofing the crypto. Anyways you can read my opinion in the comments of the last article.
It’s not clear people will choose this over other VPNs, but it could get a popularity boost now that it will be built into linux.
Just the energy savings compared to openvpn will make this a winner! But also the ease of configuration. Really great asset for Linux!
Wondercool,
Interesting thought, but it’s a blanket claim without data. I’m not sure there would be a noticeable difference, but if you find any data to back this up, I’d like to read it 🙂
Not really, ease of use has much more to do with the tooling. You still need the userland tools to configure & control it. The KDE networking applet has built in support for numerous VPNs including openvpn. Eventually wireguard will probably be another entry and make other factors more important.
It might have merit, but truthfully it’s fairly redundant with a number of alternatives. There are some definitive cons with wireguard’s reliance on hard coded parameters under the hood. Obviously wireguard runs in the kernel like IPSEC, whereas openvpn runs in userspace. Honestly I don’t know whether people will be motivated to change or not, it’s hard to predict social trends, especially without a huge corporation promoting it. We’ll see what role it eventually takes in an admin toolbox.
https://blokt.com/guides/vpn-protocols
“Just the energy savings compared to openvpn will make this a winner!”
Yes I guess it is a bit annecdotically but let me put it this way: my openvpn server regularly draws more than 5% of my CPU while wireguard doesn’t even shows up in top.
It’s very simple: openvpn is outside the kernel = more work = less efficient
“But also the ease of configuration.”
I am talking about the server here. You are talking about tooling but that the point. It’s very hard to setup OpenVpn with no tooling, too many dense parameters and a 50 page manual. Wireguard has a simple wizard. Granted Wireguard does a lot less at the moment but I think this will soon be solved.
“Really great asset for Linux!”
All my tech savvy friends are running a tunnel connection from their mobile wireless to their home server and love the battery life. It seems most VPN sites think it will be hot:
https://www.vpnranks.com/blog/wireguard-vs-openvpn/
The only negative reviews are coming from VPN providers (for good reasons: no dynamic ips, lacking features)
https://restoreprivacy.com/wireguard/
But for use case and many simple use cases: perfect!
Wondercool,
There might be some overhead, but personally I’d want to see real world measurements under reproducible conditions before being convinced it’s actually a big deal. Also to be fair, one should take into account the different crypto algorithms used (I don’t know if it’s possible to configure openvpn to use all the same algorithms…).
IMHO it’s completely fair to judge simplicity based on the tooling that normal users will have at their disposal. Most users don’t know how to setup their networking from a command prompt, but if they have desktop applets to do it for them, then the point is kind of mute.
Maybe it will, I won’t make social predictions, haha. However one point needs clarification, many of these VPN clients on mobile devices (and also mac and windows) are actually running as userspace apps. With regards to my original post above, this was kind of my point, it’s not clear to me that there’s a huge benefit in moving layer 4 protocols into the kernel (I’d like to see hard data).
There’s this ongoing debate between microkernels and monolithic kernels, wireguard in the kernel is a step in the direction of monolithic kernels. Everyone has their own opinion, but obviously not everyone will agree it’s the best approach.
While WireGuard is all well and good, there are other very interesting features that got added in 5.6.
One of the big ones for me s that they finally integrated support in the hwmon subsystem (what essentially everything uses for reading hardware thermal and power sensors on Linux) for the integrated temperature sensors on most storage devices. With 5.6, you can get temperature data from your hard drives and SSDs without needing special tooling, which is huge for some users and system integrators.
ahferroin7,
I wonder they’ve finally fixed monitoring for my motherboard’s super-io chip. I’ve written some monitoring software, but it irks me that I have no monitoring or fan control on my newest computer.
Regarding hard drive temperature via smart, I’ve stopped monitoring that information due to the caveat that it impedes my drives from going to sleep when using smartctl’s code. It sucks that I have to choose between monitoring or allowing the drives to sleep when they’re idle. Even if you explicitly put the drive to sleep, as soon as you query the temperature it wakes up. In the case of a HDD it physically spins back up. It’s a tug of war if your software is trying to put it to sleep AND monitor it. I’d be interested in seeing if the kernel monitoring has the same problem (I don’t know if this is a hardware or software limitation).
I’ll probably give this kernel a spin some time soon!
Drives are basically a consumable these days, and then we sit around wondering why young coders don’t bother to optimise!