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:Misleading Title - Wireguard exists for Linux n (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:Misleading Title - Wireguard exists for Linux n (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:Misleading Title - Wireguard exists for Linux n (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:Misleading Title - Wireguard exists for Linux n (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:Misleading Title - Wireguard exists for Linux n (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:Misleading Title - Wireguard exists for Linux n (Score:0)
What's wrong with OpenVPN?
Plenty; their site [wireguard.com] reads like a list of things that OpenVPN botched.
One of the first things you will notice, is that wireguard connects instantly and stays connected; the endpoints are identified by keys, so the addresses can change without interrupting the connection. It is especially nice to have persistent connectivity on wireless devices with flaky connections.
Re:Misleading Title - Wireguard exists for Linux n (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 to deal with issues it came to twenty-one A4 pages of instructions, including working around all the client and server bugs in implementations. After the usual review process, it was sent out to remote sites still containing the comment that "OpenVPN can die in a fire", which no-one objected to.
With WireGuard the same doc was half a page, and was accepted as its first draft, no revisions needed.
Re:Misleading Title - Wireguard exists for Linux n (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:Misleading Title - Wireguard exists for Linux n (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 might find more help over in IPsec circles. So if it is to remain relevant, OpenVPN is going to have to figure out where the sweet spot is between IPsec and wireguard and develop features for that pocket.
(BTW, IPsec is *also* hard to configure because vendors like Cisco tried to simplify it when they crammed it into the IOS CLI syntax and as such established a de-facto standard that most commercial VPN equipment vendors mimic to some extent. It's somewhat easier on modern strongswan installations than on switches and routers.)
Re:Misleading Title - Wireguard exists for Linux n (Score:2)
IPSEC is deliberately too complex to security implement and use because the NSA controlled the committee which ratified it.
Re:Misleading Title - Wireguard exists for Linux n (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 being written from scratch is not because the OpenVPN 2.x code base is so great. Itâ(TM)s really quite bad.
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:0)
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, nor does any of the server-side documentation describe how to configure allowed/disallowed algorithms or ciphers. It could be using ROT13 for all we know.
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: I'm concerned about security over time (Score:3)
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.
Re:I'm concerned about security over time (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:I'm concerned about security over time (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:I'm concerned about security over time (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 to expect.
Re:I'm concerned about security over time (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 design by committee, or because it was subverted by intelligence services to make sure few not in NSA would know how to use it correctly.
At this point in time there are only two reasonable choices for ciphers: ChaCha20 and Poly1305 (WireGuard picked this) for fast software cryptography, or AES128-GCM if you use a really weak CPU but have AES in hardware.
Re:I'm concerned about security over time (Score:0)
At this point in time there are only two reasonable choices for ciphers: ChaCha20 and Poly1305 (WireGuard picked this) for fast software cryptography, or AES128-GCM if you use a really weak CPU but have AES in hardware.
It is just unfortunate that the kernel maintainers have mandated that in-kernel wireguard be gimped by the unwieldy asynchronous crypto API, which is completely inappropriate in this use case.
Re:I'm concerned about security over time (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 APIs that do the same thing, but it's about as useful for generic crypto use as the skb_* API is for implementing a web server.
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 attacks
It GUARANTEES a downgrade attack. It makes it IMPOSSIBLE to ever use anything better than 2019 encryption. In 2025, WireGuard users will definitely be using outdated ciphers.
Re:Rapid enough? Windows does have 1.3 out of the (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:Rapid enough? Windows does have 1.3 out of the (Score:2)
Re:I'm concerned about security over time (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 unilateral upgrades and eventual removal of old cypher suites once you could tell your peers had upgraded.
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.
Re:I'm concerned about security over time (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:I'm concerned about security over time (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:I'm concerned about security over time (Score:2)
Re:I'm concerned about security over time (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:Niche (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 to IKEv2, the poor intercommunication between the layers of the IPsec/XL2TP/PPP stack resulted in a total tire fire of failure modes.
Most of the perceived difficulty of VPNs is due to a lack of good RA client UIs, and it's getting even worse with MFA/2FA trending in.
(on the RA-server side we don't need no stinkin GUIs)
Re:Not wild about it... (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 CVEs, since this is pre-release snapshot software). This text will be removed after a thorough audit."
Fuck that. (Score:0, Offtopic)
I only trust my own VPN and ipredator.se.
By the Pirate Bay guys.
I don't trust anyone (more) with this, whose one life hasn't been threatened by the state-backed organized crime (lile the Content Mafia).
Nice slashvertisent though, Five Eves / Russia / China / Israel / Iran / ... .
Re:Fuck that. (Score:3)
This is not about a VPN provider. It is about a VPN protocol.
Re:Fuck that. (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 fully encrypted and distributed internet layer would break the business models of Google and Facebook. I say Screw those assholes. We need our privacy back.
Re:Blocked in China (Score:1)
Re:Blocked in China (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:Blocked in China (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.