WireGuard VPN Is On Its Way To Linux (zdnet.com) 48
WireGuard has now been committed to the mainline Linux kernel. "While there are still tests to be made and hoops to be jumped through, it should be released in the next major Linux kernel release, 5.6, in the first or second quarter of 2020," reports ZDNet. From the report: WireGuard has been in development for some time. It is a layer 3 secure VPN. Unlike its older rivals, which it's meant to replace, its code is much cleaner and simple. The result is a fast, easy-to-deploy VPN. While it started as a Linux project, WireGuard code is now cross-platform, and its code is now available on Windows, macOS, BSD, iOS, and Android. It took longer to arrive than many wished because WireGuard's principal designer, Jason Donenfeld, disliked Linux's built-in cryptographic subsystem on the grounds its application programming interface (API) was too complex and difficult. He suggested it be supplemented with a new cryptographic subsystem: His own Zinc library. Many developers didn't like this. They saw this as wasting time reinventing the cryptographic well.
But Donenfeld had an important ally. Torvalds wrote, "I'm 1000% with Jason on this. The crypto/ model is hard to use, inefficient, and completely pointless when you know what your cipher or hash algorithm is, and your CPU just does it well directly." In the end, Donenfeld compromised. "WireGuard will get ported to the existing crypto API. So it's probably better that we just fully embrace it, and afterward work evolutionarily to get Zinc into Linux piecemeal." That's exactly what happened. Some Zine elements have been imported into the legacy crypto code in the forthcoming Linux 5.5 kernel. This laid the foundation for WireGuard to finally ship in Linux early next year.
But Donenfeld had an important ally. Torvalds wrote, "I'm 1000% with Jason on this. The crypto/ model is hard to use, inefficient, and completely pointless when you know what your cipher or hash algorithm is, and your CPU just does it well directly." In the end, Donenfeld compromised. "WireGuard will get ported to the existing crypto API. So it's probably better that we just fully embrace it, and afterward work evolutionarily to get Zinc into Linux piecemeal." That's exactly what happened. Some Zine elements have been imported into the legacy crypto code in the forthcoming Linux 5.5 kernel. This laid the foundation for WireGuard to finally ship in Linux early next year.
Misleading Title - Wireguard exists for Linux now (Score:5, Informative)
It has to insert a kernel module at the current time, but it works nicely in Linux.
That said, I'm exciting to see better integration with the kernel, and hopefully a nice performance jump. Though to be fair, Wireguard is already damn fast.
Re: (Score:2)
it's not. while the title could have included "tree", it doesn't take more than reading the first few words of the summary to know it's what they meant
Re: (Score:2)
It is. If the statement is "the title is misleading" you cannot counter with "read the summary". The statement is about the title. And the title suggests that WireGuard wasn't available before on Linux, which is untrue.
Re: (Score:2)
It also makes it more mainstream than it is at the moment.
I'm actually going to be dancing some sort of jig when this finally goes mainstream (yeah, it'll look terrible, but I'll give it a go anyway) because then it means I can finally consign the abominations that are IPsec and OpenVPN to the darkest circles of hell.
God, I'll even get wildly drunk and I don't even drink.
Re:Misleading Title - Wireguard exists for Linux n (Score:5, Informative)
What's wrong with OpenVPN? It happens to work quite well, and can do things that WireGuard cannot. Things that are sometimes important in an enterprise, like authenticating VPN users against LDAP through PAM, making it easy to grant or recall VPN access. All the client needs is the right certificate and then the user provides his credentials, which are shared over the TLS link before the VPN is brought up. Furthermore OpenVPN when operated on a TCP/IP port such as 443 is indistinguishable from https traffic. In fact you can even use a SSL multiplexer like sslh [unixmen.com] to make https, ssh, openvpn, and other protocols all work at the same time over the same port. To me sslh and openvpn are a great combination as lots of places block other ports.
Wireguard is good but it can't currently replace everything that the other vpn solutions do. Yet anyway.
Re: (Score:2)
OpenVPN is inefficient. Anything that tunnels a reliable protocol (e.g. TCP) over a reliable protocol is inefficient. It's also easy to distinguish typical VPN-like activity patterns from HTTPS-like activity patterns using a variety of heuristics.
Re:Misleading Title - Wireguard exists for Linux n (Score:4, Informative)
However WireGuard has other good things:
- It is orders of magnitude faster than OpenVPN (on a Intel Celeron J1900 I can have 400+ Mbps tunneled) while OpenVPN manages 50Mpbs.
- Much lower latency overhead (we're talking about microseconds here but it is impressive)
- Endpoint roaming on both ends (the "connection" doesn't break, the endpoints just get updated automatically, useful if you're on a wifi network and connect to a mobile one)
Re: (Score:3)
I switched from OpenVPN to Wireguard. On my 2013 Core i7 laptop the CPU was saturated to about 80% routing 25mbps, with Wireguard it's about 5%.
Wireguard connects faster and recovers from dropped connections better too. If the reconnect is quick it doesn't even break TCP streams.
Re: (Score:2)
If it wasn't for the existence of IPsec, OpenVPN would be the most difficult-to-configure piece of networking whatever I've run into since I worked with X.25. Sure, if you go with an OpenVPN provider and cut&paste their config blob into your OpenVPN client you're fine, but if you need to do custom settings of any kind you're screwed. I had to write a howto for some network admins at a global organisation for setting up OpenVPN links and after extensive back-and-forth with people using it and rewrites
Re: (Score:2)
Having set up both, OpenVPN is way, way easier than IPsec. I've never quite understood why people find OpenVPN so hard. The example configs are well documented. I've been doing custom things with OpenVPN for years with routing and subnets. Never found the documentation to be lacking.
But yes for the simple things I can see why wireguard is better. It is faster and simpler. But it's not going to replace OpenVPN for my needs.
Re: (Score:2)
IPsec is hard to configure because it does more for more use cases. OpenVPN has been the primary go-to for people doing simple, non-enterprise setups and to some extent for RA. Wireguard is even simpler but targeted even more tightly at simple L2L or very simple pre-keyed RA setups that don't have complicated routing or AAA requirements. That means OpenVPN will be getting squeezed from both sides now. If it hemorrhages active user community size to wireguard, those that need the more complex capabilities
Re: (Score:2)
IPSEC is deliberately too complex to security implement and use because the NSA controlled the committee which ratified it.
Re: (Score:2)
I've implemented it securely. It's not impossible, and the only thing the committee really did to throw a monkey wrench in was leave the initial protocol negotiation vulnerable to MiTM downgrade. It's the implementors that really screwed the pooch, especially the commodity client implementors, not the designers.
Re: Misleading Title - Wireguard exists for Linux (Score:2)
You answered your own question: OpenVPN does things which are only sometimes needed. Thatâ(TM)s another way of saying OpenVPN is bloated.
WireGuard sticks to the essentials. The accompanying wg-quick does a lot more, but itâ(TM)s not a requirement. WireGuard works fine without it.
Debloating OpenVPN has proven difficult too. Thereâ(TM)s a lot of legacy code that the developers, by their own admission, donâ(TM)t dare touch, because they donâ(TM)t know exactly what it does.
OpenVPN 3.0 b
Not wild about it... (Score:3)
I mean it works, and well, but I wish there were better logging (unless maybe I'm missing something), and I really liked both the docs and HOWTOs that came with OpenVPN. Hopefully now that it's being merged, docs will pick up some. Sadly for the prior poster, there will be no speed bump -- loading a module compiled out-of-tree is identical in performance to having it in-tree.
I'm concerned about security over time (Score:5, Interesting)
Reading their description of the protocol, I see a potential problem.
I'm hoping it just wasn't described clearly and they've actually addressed this, but it doesn't sound like they have.
They wanted to make it simpler than IKE + IPsec, or TLS VPNs.
To that end, they got rid of the IKE cipher negotiation step and seem to have hardcoded particular algorithms, both ciphers and MACs. There is a darn good reason the IKE+IPSec and TLS have that "complicated" negotiation step.
The best and the acceptable algorithms for cryptography are always changing, due to the nature of the race between those who try to crack cryptography and those who try to make it uncrackable. Clever people come up with new attacks about once or twice per year.
I suggest that people check their crypto settings about two per year, and plan on making adjustments probably once per year on average. If, as it seems, WireGuard doesn't negotiate ciphers, modes and MACs, that's going to be a problem. You'll be stuck with older, insecure selections unless everyone updates at the same moment - and WireGuard might not make that easy. Sure the algorithms and modes they chose are considered secured today; they might not be a year from now or two years from now.
I haven't stepped through the code yet, so it may be better than it first appears. I think I will need to look through the code before I could sign off on installation I'm responsible for to be using it.
Re: I'm concerned about security over time (Score:3)
Vs lbh nfxrq Oehpr Fpuarvre gb qrpelcg guvf, ur'q pehfu lbhe fxhyy jvgu uvf ynhtu.
Re: (Score:3)
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.
Re: (Score:3)
You're not wrong. The docs say, "WireGuard is an extremely simple yet fast and modern VPN that utilizes state-of-the-art cryptography." But doesn't describe any of the algorithms nor ciphers that it supports
Literally the very first Google hit for the term "wireguard", for WireGuard's Wikipedia entry, says "WireGuard utilizes Curve25519 for key exchange, ChaCha20 for encryption, and Poly1305 for data authentication, SipHash for hashtable keys, and BLAKE2s for hashing.[3] It supports layer 3 for both IPv4 and IPv6 and can encapsulate v4-in-v6 and vice versa.[5]".
Mind you with that level of reading comprehension fail, perhaps a Rot13-based VPN would actually be the safest for you.
Re: (Score:2)
> WireGuard utilizes Curve25519 for key exchange, ChaCha20 for encryption ...
Yeah it looks like it's at with those no matter what attacks come out. Bad idea.
> with that level of reading comprehension fail, perhaps a Rot13-based VPN
That was rude. Do you talk to people at work like that?
Re: (Score:1)
> WireGuard utilizes Curve25519 for key exchange, ChaCha20 for encryption ...
Yeah it looks like it's at with those no matter what attacks come out. Bad idea.
Not at all; the cryptographic primitives are well studied and conservative. They are good, high-performance algorithms on virtually all hardware, and the lack of choice prevents bad choices, which is a greater concern.
In the highly unlikely event that replacement of the primitives is necessary or desirable, they will release v2 and deprecate the old version. The simplification of the protocol is well worth it, and the packet payloads appear as nothing but random data, with the endpoints knowing exactly what
Re: (Score:2)
"Everyone" uses AES256 with SHA1 and DH group 2 (sometimes 5), and IKEv1 aggressive mode. Security level just above ROT13.
Not having protocol negotiation is a major advantage. It stops downgrade attacks and it prevents idiots from picking the wrong settings. TLS would have been better off without protocol negotiation, TLS changes version at a rapid enough pace that the new protocol version could tie in with cryptography development.
IPSEC is intentionally complex either because it is an extreme example of de
Re: (Score:2)
designed to work with acceleration hardware and allow sophisticated composition of operations, requiring users to do things like set up transform contexts and scatter/gather lists for the data to be encrypted. But most users simply want to perform a simple cryptographic operation and do not benefit from the complexity of the kernel's API, so developers tend to avoid it.
This pretty much sums up everything that's wrong with the kernel API. It's so complex and has so much overhead that if all you need to do is "encrypt this with that key" it's vastly slower using the kernel API than doing it yourself in software, and insanely slower for small data quantities where the setup overhead dominates. It's a standard-ish interface for high-end crypto hardware, and a great replacement for device/vendor-specific
Rapid enough? Windows does have 1.3 out of the box (Score:3)
> , TLS changes version at a rapid enough pace that the new protocol version could tie in with cryptography development.
Out of rhe box, Windows does, I think 1.1, maybe 1.2.
1.0 was ten or eleven years ago. So the TLS version changes every five or ten years.
Around the time of POODLE, safe cipher settings were changing every month or two as we figured put how to deal with multiple types of attacks against different configurations.
> Not having protocol negotiation is a major advantage. It stops downgrade
Re: (Score:2)
Around the time of POODLE, safe cipher settings were changing every month or two as we figured put how to deal with multiple types of attacks against different configurations.
I am sure both of the people changing the settings on their VPN tunnels every month or two were very grateful for the configurability.
Meanwhile real tunnels are AES256-SHA1-DH2. Except for the ones that are 3DES-MD5-DH1.
Re: (Score:2)
Re: (Score:2)
Not having protocol negotiation is a major advantage. It stops downgrade attacks and it prevents idiots from picking the wrong settings.
I half agree. In real-world use the protocol negotiation feature is broken, even in IPSec. Out of the box every client is preconfigured for maximum compatibility to talk to legacy VPNs, and with am MITM even in IPSec this can be downgraded... and we have plenty of MITMs these days in the age of insecure home routers.
In an ideal world, protocol negotiation would be integrity-protected, but not concealed, such that external security tools could warn of badly parameterized tunnels.
This would allow for unilat
Re: (Score:2)
We should be preparing for the eventuality that we will need to move to post-quantum suites. Those aren't fully assessed yet, so we have to be able to do that when they are ready.
There are not very many crypto protocols in actual use. Basically there is TLS, nonstandard-TLS-over-UDP in a million variants (one of them is OpenVPN), IPSEC, MACSEC, and now WireGuard. Bumping the protocol version for the quantum resistant crypto is not a huge task for such a small amount of protocols.
The gazillion TLS-over-UDP variants are a problem of course. Don't do that then.
Re: (Score:2)
The problem is you don't just "bump a protocol version," call it a night, and go home IRL.
I think it would behoove wireguard to come up now with an action plan on how to gracefully upgrade a large in-service network of connections with minimal coordination between different elements of the network and minimal disruption to service. If they can produce that without utilizing a negotiation protocol, then no harm no foul.
Re: (Score:2)
Re: (Score:2)
Yeah I think hoverboards used AES in rhe 1970s. :)
Btw CBC modes are vulnerable to Zombie POODLE, GOLDENDOODLE, 0-Length OpenSSL, Sleeping POODLE, and more.
So no, your suggestion is neither old nor safe.
Re:Not wild about it... (Score:5, Interesting)
I really liked both the docs and HOWTOs that came with OpenVPN.
Yeah, thanks to those excellent docs - OpenVPN is not hard to set up at all.
I haven't seen much said, one way or the other, about WireGuard's security. The fact that Linus is backing this is important, for sure; but I really want to hear more from people who seem to really get security. Quick reconnects are great, but it's not as if my OpenVPN connection breaks much at all... so how much do quick reconnects really matter in practical terms?
And I'd also like to know how well or poorly the Windows implementation works. In the end, that's probably what will be the main determiner of whether this ends up being widely adopted, or is just a niche product (as OpenVPN sorta is, frankly).
Niche (Score:3)
Agreed that OpenVPN is niche, but disagree as to why: it's had perfectly acceptable Windows support for ~20 years. Just not sure where it lost its momentum, or why, as it was so superior to other options -- commercial and free -- for quite some time.
Re: (Score:2)
I think the client support for OpenVPN has been probably one of the major contributers to its popularity. Windows support for IPsec has always been a total kludge... bifurcated between the more or less crippled Agile RA client and the impossibly stuffy enterprise features. OSX support isn't much better and actually got worse over time as they forced more and more of the config out of the UI and into the .mobileconfig. Linux UI configurators for client-side IPsec-RA are missing critical features and prior
Re: (Score:3)
Quick reconnection and not breaking TCP connections is very valuable for mobile users, it even just people stuck with crappy WiFi.
Cryptographic well? (Score:1)
PSA (Score:2)
"Work in Progress
WireGuard is currently working toward a stable 1.0 release. Current snapshots are generally versioned "0.0.YYYYMMDD" or "0.0.V", but these should not be considered real releases and they may contain security quirks (which would not be eligible for CV
Re: (Score:3)
This is not about a VPN provider. It is about a VPN protocol.
Re: (Score:2)
What are you talking about?
This is not about a VPN provider. It is about a VPN protocol.
Paranoia is detrimental to the ability to see reality...
Sidebar: How can you really trust any VPN? (Score:2)
Blocked in China (Score:2)
The great midget hitler already has automatic detection of all standard protocols, including wireguard. I've tested this in China and found it gets detected, connections reset, and then your connection starts to show extremely degraded performance, probably due to being subject to extra deep packet inspection after detection. What we need is a replacement for traditional VPN - actually, a replacement for the traditional internet. The only reason we are not talking about this more is because making a new
Re: (Score:1)
Re: (Score:2)
I've tested this in China and found it gets detected, connections reset, and then your connection starts to show extremely degraded performance, probably due to being subject to extra deep packet inspection after detection.
UDP is stateless so how could it be reset?
Re: (Score:3)
It's true, UDP has no "connection" to reset, this is only happening if you use TCP, which I sometimes have to do because UDP completely stops working. At times around the CCP congress meetings and HK protests it seems like all unregistered UDP connections are blocked. They are moving closer and closer to a white listed intranet.