WireGuarding the mainline

https://lwn.net/SubscriberLink/761939/4cee93b4fe564556/

by thinxer • 8 years ago

206 95 8 years ago

mirimir7• 8 years ago

Quoting Linus Torvalds:[0]

I see that Jason actually made the pull request to have wireguard included in the kernel.
Can I just once again state my love for it and hope it gets merged soon? Maybe the code isn't perfect, but I've skimmed it, and compared to the horrors that are OpenVPN and IPSec, it's a work of art.

0) https://lwn.net/ml/linux-kernel/CA+55aFz5EWE9OTbzDoMfsY2ez04...

Edit: fixed URL

mberning• 8 years ago

An incredible compliment to be sure.

deelowe4• 8 years ago

But in true Linus style, he just has to take a dig at another team at the same time to balance things out.

pfranz• 8 years ago

That's great to hear, but I wonder if anyone has insight on the rest of the article. Is this Zinc API a prerequisite for WireGuard to be included? Is the fact that Zinc won't support hardware encryption a no-go or is the expectation they give reasonable? Has the kernel had any large API refactoring similar the crypto/Zinc (I would assume it has)--how did they play out?

caf• 8 years ago

There seems to be broad agreement for the need for a set of software crypto implementations with a straightforward synchronous, static dispatching API. The discussions seem to be mainly around code organisation and plumbing that API as an underlying implementation used by the dynamic dispatch asynchronous crypto API.

jwilk• 8 years ago

Fixed link: https://lwn.net/ml/linux-kernel/CA+55aFz5EWE9OTbzDoMfsY2ez04...

mirimir7• 8 years ago

Thanks :) I'm not sure how that happened.

ghayes• 8 years ago

Off topic: Does anyone have a good tutorial on setting up Wiregaurd on a cloud server to act as a VPN? I’m currently using Algo from Trail of Bits, which is great, but takes a lot on control out of my hands through its Ansible scripts.

zwily• 8 years ago

https://github.com/StreisandEffect/streisand will do WireGuard.

iampims• 8 years ago

https://www.timdoug.com/log/2018/08/04/#wireguard_macos

https://www.stavros.io/posts/how-to-configure-wireguard/

should be sufficient to help you set it up.

bubblethink• 8 years ago

Official documentation and the arch wiki (https://wiki.archlinux.org/index.php/WireGuard) are good sources

mirimir7• 8 years ago

Others have posted great links. But one great aspect is how simple it is. The hardest part is getting a kernel module that works with your kernel. In my experience, the best way to do that is to build it. And that's the hardest part in getting WireGuard working. In Debian, that means using the latest stable release (at least) with the latest kernel.

Once you have WireGuard working, creating tunnels is utterly trivial. For a toy implementation:

    peer 0 with IPv4 address 1.2.3.4
    
    # ip link add dev wg0 type wireguard
    # ip link list
      [see wg0]
    # wg genkey | tee privatekey | wg pubkey > publickey
    # mkdir wg
    # mv privatekey publickey ./wg/
    # ip address add dev wg0 10.0.10.1 peer 10.0.10.2
    # wg set wg0 listen-port 51820 private-key ~/wg/privatekey
    # ip link set wg0 up
    # wg
      interface: wg0
        public key: 0GS...0U=
        private key: (hidden)
        listening port: 51820
    # wg set wg0 peer IlC...QI= allowed-ips 0.0.0.0/0 endpoint 6.7.8.9:51820
    
    peer 1 with IPv4 address 6.7.8.9
    
    # ip link add dev wg0 type wireguard
    # ip link list
      [see wg0]
    # wg genkey | tee privatekey | wg pubkey > publickey
    # mkdir wg
    # mv privatekey publickey ./wg/
    # ip address add dev wg0 10.0.10.2 peer 10.0.10.1
    # wg set wg0 listen-port 51820 private-key ~/wg/privatekey
    # ip link set wg0 up
    # wg
      interface: wg0
        public key: IlC...QI=
        private key: (hidden)
        listening port: 51820
    # wg set wg0 peer 0GS...0U= allowed-ips 0.0.0.0/0 endpoint 1.2.3.4:51820

berti• 8 years ago

Your distro's wireguard-dkms package is your friend.

rsync• 8 years ago

"Others have posted great links. But one great aspect is how simple it is."

(generate new keys to manage, create new network interfaces, assign new IPs, run wireguard ...)

I would agree that this is relatively simple but only compared to the other mainstream options (namely, OpenVPN and IPSEC) but it is much, much more complicated than sshuttle[1] which distinguishes itself by allowing you to use any ssh server as a VPN endpoint.

No server side software install is required - all you need on the endpoint is an ssh login.

[1] https://github.com/sshuttle

voltagex_• 8 years ago

That's... not trivial.

oarsinsync2• 8 years ago

That's about as trivial as compiling a custom kernel. Possibly less so, as compiling a kernel in Debian/Ubuntu takes less than 10 commands.

zigzaggy• 8 years ago

Just finished spinning up streisand to run Wireguard on my home network. This is my second time around with this set up, and it works great for me.

https://github.com/StreisandEffect/streisand

trumped4• 8 years ago

using a cloud server as your VPN? what made you come to that decision? how is that better then your ISP?

hueving• 8 years ago

The cloud providers havent shown themselves to be scum like some of the ISPs that happily inject Javascript into your http traffic.

cookiecaper• 8 years ago

Comcast connections are metered for most residential users. Additional costs are incurred after 1TB of transfer. Also, home uplinks are generally pretty slow, and the VPN will be bottlenecked by its up speed.

jlgaddis• 8 years ago

In my case, I work for an ISP -- althoug not my ISP -- and the "cloud server" is a small virtual guest (that I manage) in one of $work's facilities. Between $work and AT&T (my home ISP), who do you think I trust more?

Many people have very little choice when it comes to the ISP they use. By setting up a "cloud server", at least they get to decide who, i.e. which cloud provider, has access to their traffic -- and can switch between providers much easier and at any time they wish.

pingec• 8 years ago

Wireguard looks awesome. Any news about a windows wireguard implementation?

kbaker• 8 years ago

There's TunSafe, BUT with caveats: https://news.ycombinator.com/item?id=16515637

ludde• 8 years ago

TunSafe is Open Source nowadays so most of those caveats are moot.

microcolonel• 8 years ago

Andy Lutomirski was generally favorable as well, noting that he has tried to carry out some similar changes to the cryptographic code in the past. Support for hardware accelerators should, he said, be built on top of Zinc; code needing that support could then use the more complex API that would be required, and the Zinc implementations could be used as fallbacks when acceleration is not available or practical to use.

This seems like a flawless approach. The Zinc approach seems to be preferred (by those involved) for simple software-only use cases, and the more complex use cases seem to be composed of operations which Zinc could implement.

It's good that they're not just going to plop the thing in there in a degraded state (with probably worse performance [and DoS resistance] than the current out of tree/dkms distributions of wireguard).

zx2c44• 8 years ago

It's good that they're not just going to plop the thing in there in a degraded state (with probably worse performance [and DoS resistance] than the current out of tree/dkms distributions of wireguard).

Yea, indeed, I'm really trying to get the mainline version to have the same performance and security characteristics as the out-of-tree module version.

(And after it's mainlined, the out-of-tree module will only exist as compatibility for older kernels, and I'll have some scripts to automatically extract a mainline kernel into a backport.)

nickpsecurity2• 8 years ago

"He pointed out that Zinc cannot support hardware cryptographic accelerators, something that Donenfeld regards as a feature. "

Why is not supporting hardware acceleration a feature? Or is the objection to something more specific having to do with currently-available accelerators?

evil-olive• 8 years ago

The idea is that hardware acceleration is a niche feature, so it should be kept out of the core, low-level crypto primitives, and then a higher-level API can be built that allows dynamic dispatch to an accelerator if available:

https://lkml.org/lkml/2018/8/3/15

A very large majority of in-kernel crypto users (by number of call sites under a very brief survey, not by number of CPU cycles) just want to do some synchronous crypto on a buffer that is addressed by a regular pointer. Most of these users would be slowed down if they used any form of async crypto, since the CPU can complete the whole operation faster than it could plausibly initiate and complete anything asynchronous. And, right now, they suffer the full overhead of allocating a context (often with alloca!), looking up (or caching) some crypto API data structures, dispatching the operation, and cleaning up.
So I think the right way to do it is to have directly callable functions like zinc uses and to have the fancy crypto API layer on top of them. So if you actually want async accelerated crypto with scatterlists or whatever, you can call into the fancy API, and the fancy API can dispatch to hardware or it can dispatch to the normal static API.

nickpsecurity2• 8 years ago

That makes sense. Thanks!

floatboth• 8 years ago

I guess they don't count CPU instruction based accelerators like AES-NI as accelerators?

efiecho• 8 years ago

I'm really looking forward to start experimenting with Wireguard. Jason A. Donenfeld is also the creator of my favorite password manager https://www.passwordstore.org/ and recently I found a neat web frontend for git called cgit, lo and behold, when I looked it up I saw that Jason was the creator. He makes some really cool high quality stuff.

Boulth• 8 years ago

He makes some really cool high quality stuff.

Couldn't agree more, all of his software is really nicely designed and implementated. Moreover I had a chance of exchanging emails with him and he's a really nice person.

tptacek4• 8 years ago

He really is. We just got done hanging out with him at Black Hat, and he's one of the nicer people I've met here. A+++ would hang out again.

andreareina• 8 years ago

Does anyone know why reverse christmas tree order of declarations (i.e. longest to shortest line length) is part of the style guide?

hinkley• 8 years ago

I’m wondering that too. What happens when a variable is initialized as a consequence of the state of two other variables (which would tend to be a longer statement)?

catwell4• 8 years ago

I don't know in their case, but I know it's the style used by Hisham Muhammad (author of htop and LuaRocks among other things), and he explained why here: https://hisham.hm/2018/06/16/when-listing-repeated-things-ma...

Animats3• 8 years ago

That this has to be in the kernel is a failure of the Linux architecture. This is middleware.

tptacek4• 8 years ago

Sure. It is middleware in the same sense that an encrypted filesystem is middleware.

catwell4• 8 years ago

The only reason for it to be in the kernel is performance. There are userspace implementations already, like on Windows and macOS.

rwmj4• 8 years ago

Because everyone knows kernel code runs faster than userspace code, right? Er no, because of architectural problems.

rwmj4• 8 years ago

If you like that, you'll love FIPS kernel cryptography!

chrisper2• 8 years ago

Does anyone know a good Windows client?

I only know TunSafe, which now has finally been open sourced. But it was still controversial software. So any alternative would be nice.

nostream2• 8 years ago

I've never really understood what was controversial with TunSafe more than it was closed source so it was hard for others to review the code, but now it's open source.

As a former fan of WireGuard, I would STRONGLY advise against using ANY WireGuard implementation and that includes the official one.

As it is now, there seems to be only one person in the world who believes that they have the knowledge to determine if a WireGuard implementation is secure or not, and it is the founder himself.

So much for the 4000 lines of code that was supposed to be easily audited and understandable by others.

Avoid WireGuard until there is an outside group that can review the protocol and implementations of the protocol. For as it is now, the founder accuses all third party implementations of being unsecure but without being able to state why (more than it feels he has something personal against them).

It all feels too immature.

pimeys• 8 years ago

A couple of days ago I started testing with WireGuard and installed it to my Omnia Turris router. Mullvad provides WireGuard servers[0] for testing with a reasonable price, and I've been routing all the traffic from our apartment through WireGuard without any problems. The speed is just amazing after seeing the disappointing performance of OpenVPN, I can easily push 300-400 MB/s through the router, finally removing the last reason to not use a VPN for all the traffic.

[0] https://mullvad.net/en/guides/category/wireguard/

vardump2• 8 years ago

I can easily push 300-400 MB/s

Wow. (For Wireguard performance and the link speed.)

10 Gbps link or just on the local network?

namibj• 8 years ago

I presume a typo....

Kurtz79• 8 years ago

What is the status of WireGuard in terms of client device support?

The main advantage of IPsec and OpenVPN is that they are either natively supported by all major OSs (desktop and mobile) or there are apps freely available for that purpose.

chupasaurus• 8 years ago

Linux, Android and macOS (through brew app) are supported, Windows and iOS clients are in development.

WireGuarding the mainline

Related Stories