Linus Torvalds Pulls WireGuard VPN into Linux 5.6 Kernel Source Tree (techradar.com) 51
"The WireGuard VPN protocol will be included into the next Linux kernel as Linus Torvalds has merged it into his source tree for version 5.6," reports TechRadar:
While there are many popular VPN protocols such as OpenVPN, WireGuard has made a name for itself by being easy to configure and deploy as SSH... The WireGuard protocol is a project from security researcher and kernel developer Jason Donenfeld who created it as an alternative to both IPsec and OpenVPN. Since the protocol consists of around just 4,000 lines of code as opposed to the 100,000 lines of code that make up OpenVPN, it is much easier for security experts to review and audit for vulnerabilities.
While WireGuard was initially released for the Linux kernel, the protocol is now cross-platform and can be deployed on Windows, macOS, BSD, iOS and Android.
Ars Technica notes that with Linus having merged WireGuard into the source tree, "the likelihood that it will disappear between now and 5.6's final release (expected sometime in May or early June) is vanishingly small." WireGuard's Jason Donenfeld is also contributing AVX crypto optimizations to the kernel outside the WireGuard project itself. Specifically, Donenfeld has optimized the Poly1305 cipher to take advantage of instruction sets present in modern CPUs. Poly1305 is used for WireGuard's own message authentication but can be used outside the project as well — for example, chacha20-poly1305 is one of the highest-performing SSH ciphers, particularly on CPUs without AES-NI hardware acceleration.
Other interesting features new to the 5.6 kernel will include USB4 support, multipath TCP, AMD and Intel power management improvements, and more.
While there are many popular VPN protocols such as OpenVPN, WireGuard has made a name for itself by being easy to configure and deploy as SSH... The WireGuard protocol is a project from security researcher and kernel developer Jason Donenfeld who created it as an alternative to both IPsec and OpenVPN. Since the protocol consists of around just 4,000 lines of code as opposed to the 100,000 lines of code that make up OpenVPN, it is much easier for security experts to review and audit for vulnerabilities.
While WireGuard was initially released for the Linux kernel, the protocol is now cross-platform and can be deployed on Windows, macOS, BSD, iOS and Android.
Ars Technica notes that with Linus having merged WireGuard into the source tree, "the likelihood that it will disappear between now and 5.6's final release (expected sometime in May or early June) is vanishingly small." WireGuard's Jason Donenfeld is also contributing AVX crypto optimizations to the kernel outside the WireGuard project itself. Specifically, Donenfeld has optimized the Poly1305 cipher to take advantage of instruction sets present in modern CPUs. Poly1305 is used for WireGuard's own message authentication but can be used outside the project as well — for example, chacha20-poly1305 is one of the highest-performing SSH ciphers, particularly on CPUs without AES-NI hardware acceleration.
Other interesting features new to the 5.6 kernel will include USB4 support, multipath TCP, AMD and Intel power management improvements, and more.
Actual article link (Score:5, Informative)
You can read the actual article here. [bleepingcomputer.com] The link from the summary is a dumbed down and ad laden version.
VPN - Kernel... (Score:1)
VPN -> Kernel... (Score:2)
How to upgrade from Windows 7 to Ubuntu (Score:3)
How to upgrade from Windows 7 to Ubuntu -- Hardware and software considerations -- by Igor Ljubuncic [ubuntu.com] (Ubuntu.com, Jan. 28, 2020)
Re: (Score:2)
Re: (Score:2)
4k vs 100k lines (Score:1)
Makes you wonder what the other 96k lines of code are doing if you can achieve the same thing (if not better) in 4k lines..
Re:4k vs 100k lines (Score:5, Informative)
It is not quite a fair comparison, as one is in-kernel and the other one is external. Still, smaller is decidedly better and using all the kernel routing stuff instead of doping its own thing like OpenVPN has its advantages.
Re: (Score:2)
It's fair enough. Using the Linux kernel API, it doesn't take that much code to access networking from userspace using a tap device and raw sockets. That's a small fraction of the excess lines of code.
Re: (Score:2)
One would have to compare feature sets to see what Wireguard does - and doesn’t do - compared to OpenVPN and the others. Wireguard is intended to be simple by design, so I wouldn’t be surprised if OpenVPN does a number of things Wireguard doesn’t.
But then one would also have to ask if any “missing” features really belong inside the VPN proper’s codebase anyway, or are better handled by other external processes.
Re: (Score:2)
But then one would also have to ask if any “missing” features really belong inside the VPN proper’s codebase anyway, or are better handled by other external processes.
Very much a valid question. Given the vast difference in audit-ability, the features would have to be damned important.
Given that WireGuard is apparently perfectly usible, there's a good chance the difference is feeping creaturism.
I know that IPSEC is certainly overly baroque for what it offers.
Re: (Score:2)
As I read Wireguard's website, it is supposed to be simpler to configure than Ipsec/*SWAN and more performant than OpenVPN.
OpenVPN is really quite simple to configure. I don't think the author of Wireguard is claiming that Wireguard is simpler to configure than OpenVPN.
The advantage of Wireguard is that, with an order of magnitude fewer lines of code, it's easier to audit.
Re: 4k vs 100k lines (Score:2)
In my experience, wireguard actually IS simpler to configure than openvpn. For one thing there are far fewer options, so a lot less to keep track of and decide on. From a client perspective, all you really need to enter is a gateway IP, the local IP, the server public key, and your private key. There's also an optional NAT keep-awake time value, and an optional pre-shared key. That's it. The server side is almost as simple. The only thing which makes it slightly more difficult to set up is lack of DH
Re: 4k vs 100k lines (Score:2)
Why does a VPN need a DHCP client built in? All a VPN needs is to expose the interface and your DHCP client of choice can then configure addresses, routes, etc.
Re: 4k vs 100k lines (Score:2)
It doesn't. I'm not suggesting that wireguard should have one. You could implement your own DHCP type solution over a wireguard tunnel but it would be a bit tricky. Personally I don't need or want it, but there are some use case where static IPs aren't optimal.
Re:4k vs 100k lines (Score:5, Informative)
Makes you wonder what the other 96k lines of code are doing if you can achieve the same thing (if not better) in 4k lines..
You can't achieve the same thing. You can achieve one particular simplified configuration.
TCP support? No.
4096 bit keys? No.
certificates? No.
Dynamic addessing / DHCP support? No. Roll your own solution.
Duo or other 2FA integration / pki & certificates / RADIUS / LDAP? Other authentication methods? No. Just Preshared keys.
DNS redirection? Not in scope. Do that yourself.
Identity hiding forward secrecy? No.
etc..
This is not criticism of wireguard. It's 4k loc. It does one thing and does it well. But lets not act like openvpn needs a couple orders of magnitude more code to do the same thing. It needs more code because it does more stuff.
Re: (Score:1)
Re: (Score:1)
I use to have a compiled reverse vnc my parents executed, but have since been using teamviewer.(free for personal use)
no dinking around with firewalls for ether party, just a 1 time code generated at run
Re: (Score:2)
https://www.hootoo.com/p/wirel... [hootoo.com]
With OpenWRT
I found mine for under $10
Re: 4k vs 100k lines (Score:2)
Out of curiosity has anyone seen a good remote access vpn say for debugging one's parent's computers? I'd need something in a router that can connect to a cellular hotspot at one house and just a regular box of some kind at my end. It needs to just work, seldom ever need reset. Bonus points if it has ethernet connections. Basically though it would need to be remotely managed via that VPN. I'm not interesting in a diy solution unless its bullet proof.
Yeah, wireguard running on an openwrt router. I have the home networks of 5 different friends and relatives tied to mine in exactly that way; their router creates a wireguard tunnel to my $5 VPS, which routes between them and my home network. If you want to avoid the VPS you can run wireguard as a server on your own router (or home computer, whatever).
Re: (Score:2)
Both OpenVPN and IPsec are bloated crawling horrors. Wireguard is fantastic, it's just just enough to do most of what you need most of the time. Yes, IPsec and OpenVPN have triple lubricated reciprocating sliding paff gongbudgers and can hold that over Wireguard, but the only thing you can do with a triple lubricated reciprocating sliding paff gongbudger is point out that you have it and the other guy doesn't. Apart from that it offers no benefit.
And that's the case with a lot of the IPsec/OpenVPN "fea
Re: (Score:2)
Wireguard is fantastic. I'm not saying otherwise.
But I like the authenticator app + PIN + client certificates I've got going with openVPN.
I also like DHCP working over the VPN; handing out addresses, DNS suffix and DNS servers.
Re: (Score:3)
4k lines is just the implementation of the protocol. OpenVPN is a complete package and does a lot more out of the box such as configuring bridges, tunnel interfaces and routing, shaping etc. It's also cross-platform so it has to implement certain things for each platform and (if you want to keep it sane) implement some virtual common layer
All development starts small, but as you find edge and use cases, people want more features or you need some functionality you forgot to add, the project begins to grow. O
Re: (Score:2)
But ideally, you keep that small core that is critical to security separated out so it can be audited for security.
Cipher negotiation. Which is massively important (Score:5, Interesting)
I've looked at the docs, I've looked over the code, and I can't believe this is getting merged as it is - with a single hard-coded cipher suite. We recommend revising your list of acceptable cipher suites every 3-12 months, because vulnerabilities crop up often. This seems insane to me.
OpenVPN, IKE/IPsec, etc have lasted for decades because what they are is a framework for selecting and using a ciphersuite. WireGuard is one ciphersuite. That's like if we hardcoded an RC4-only VPN into the kernel. RC4 lasted a few months after it became heavily used (after POODLE).
This is just crazy to me.
For those who don't know what a ciphersuite is or what IKE is, it's the difference between IPsec being a web browser and WireGuard being a single web page. A web page is a lot smaller and easier to audit than a web browser. That's all good until you're done with that page.
Re: (Score:2)
OpenVPN, IKE/IPsec, etc have lasted for decades because what they are is a framework for selecting and using a ciphersuite. WireGuard is one ciphersuite. That's like if we hardcoded an RC4-only VPN into the kernel. RC4 lasted a few months after it became heavily used (after POODLE).
I have said this to you before, and I will say it to you again. NOT hard-coding a cipher-suite is insane. IPSEC is broken and insecure because half the tunnels out there are AES256-MD5-DH2. (And a good bit of the rest are running DES-MD5-DH1).
Everyone knew RC4 was crap. Right from the start.
Re: (Score:2)
That doesn't make IPSec broken or insecure, simply because someone copy-pastes a 10-year old recipe, doesn't mean that the protocol itself is broken. You also have to know that Cisco PIX gear for example is still everywhere and doesn't go beyond DES and RC4.
They'd ALL be broken (Score:2)
You make a fair point that people configure bad ciphers, so SOME installations aren't aee secure as they could be.
And if IPSec had hard-coded a single cipher suite back in 1995, ALL installations would have been irreparably broken by 1999.
Re: (Score:2)
Unless, you know, IPSec was upgraded to a new, safe version which would have undoubtedly happened.
Re: (Score:2)
Yea, undoubtedly they would all be changed out for a new thing. Just like they all got their configuration updated to remove CBC.
Re: (Score:2)
A new version of WireGuard is picked up by simply upgrading the kernel which you should do anyway as opposed to some obscure configuration that most sysadmins do not really understand and they would have to follow closely some cryptographic discussion which they also do not really undestand.
Re: (Score:2)
Yeah, switching to a new kernel is much simpler and lower impact than updating a config file.
Just curious, what time zone are you in? I guess maybe in Germany it's drinking time right now?
Re: (Score:2)
Because software can never be updated, and devices never get firmware updates that implement new ciphers and algorithms.
That's the claim (Score:2)
That's the assertion GP made - because some people don't update the ciphersuites, we should make it impossible to update the cipher suites, by hard-coding a single one, baked right into the software and fhe spec.
Re: (Score:2)
If IPSEC had hard-coded a single cipher suite back in 1995, half the NEW installations in 2019 I had to deal with would not have been AES256-SHA1-DH2. Some would have been IKEv4 and they would only support AES(something, who cares)-GCM, and the rest would have been IKEv3 with AES-SHA256-DH14. Both would be reasonably secure.
The only people gaining from cipher selectability in IPSEC are intelligence agencies and industrial spies.
Re: (Score:2)
IKEv4 and v3 existed in 1995?
I don't remember that.
I also don't remember AES existing, so I'm not sure how the hardcoded cipher would have been AES-anything.
Re:Cipher negotiation. Which is massively importan (Score:4, Interesting)
Re: (Score:2)
People do sometimes configure bad ciphers. That's certainly true.
If IPsec had hard-coded the best cipher in 1995, all installations would have been hopelessly broken 15 years ago. As it is, most installations are quite secure, and NONE are as insecure as they would be with a 1995 ciphersuite coded in.
> Wireguard doesn't have to worry about these attacks.
Wireguard doesn't have to worry about attacks until next month.
My current postgrad project I'm working on right now is to break a ciphersuite.
Re: (Score:3)
What will happen when the ciper is broken, is that it'll get patched and everyone will be told to upgrade - not dissimilar to what happened with the SSL libraries that needed patching.
You realize it's mostly broken now, right? (Score:3)
> What will happen when the ciper is broken, is
You do realize ChaCha20 is mostly broken now, right?
If you send more than 256Gib over the connection, that reveals the key. For several years it's been known that people have broken 7 rounds of ChaCha. Once you've broken 7, you're not that far from breaking 20 iterations.
Re: (Score:2)
Well it's sure a good thing that the entire world didn't get hacked when OpenSSL Heartbleed was a thing.
Oh wait, patches can be distributed. And are. All the time.
Re: (Score:2)
So you're thinking it's better to release a "patch" that completely replaces the entire protocol spec and the entirety of the software, making it absolutely incompatible, vs updating the config file? That's an interesting thought.
Wtf? A real tech article? (Score:1, Offtopic)
Raspberry pi (Score:2)
Re: Raspberry pi (Score:2)
So is not having no encryption at all.
Alsoy since when is OpenVPN a hassle? Install with package manager, fill out the config file template and save as your config file, run the daemon, done.
The client's config file is done the same way, but simpler.
What part of reading the description of a setting, and choosing what you like, is a hassle?
And yes, I run OpenVPN on my Pi-compatible ARM-based SBC. In fact I use it on my phone to post this very comment.
Re: (Score:2)
In an ideal world security should be a turn-key solution. OpenVPN isn't so bad so long as you're familiar with enough of the terminology that you can muddle your way through and focused-google what specifics need fixing. The best thing you can say about OpenVPN is that its barrier to entry is high enough that people who don't know what they are doing are more likely to give up than implement an insecure version. TLS is the opposite. There's so much information out there on how to get Apache+SSL working that
"Easy" is not what I'm looking for. (Score:2)
When I'm looking to be safe.
Sure, a moped is super-easy. With very few pieces of metal And a tank is super-inconvenient. With a huge amount of metal. But you're not gonna choose the former to cross a battle field.
And yes, amount of metal is a good analogy for "lines" of code. Highlighting that while it is more shit that could break, it is also more corner cases that somebody thought about! In any case, it is a silly way to measure anything, and its usage should not be ecouraged.
Usually, a new project simpl
Great! (Score:1)