
WireGuard: next generation in-kernel modern VPN - Aissen
https://www.wireguard.io/
======
zx2c4
Wow, I launched this 10 minutes ago and somebody already put it on Hacker
News. Spectacular!

I'm the author of this and would be happy to answer any questions you have.

~~~
Aissen
Yes, guilty as charged. Ever since I saw you presentation in Paris in last
September, I was dying for wireguard to come out.

I'm curious what will be your strategy with regard to working or not with
upstream Linux ?

~~~
zx2c4
Oh cool you came to the kernel recipes talk. Much has progressed since then.

I wrote an email on LKML and netdev today to David Miller, the network
subsystem maintainer. It's not ready for a [PATCH] set now, but it is ready to
get initial feedback from them, so that I can start to get things ready for
upstreaming. So: that's on the roadmap and a primary objective!

~~~
loeg
Would you mind dual-licensing under a more permissive license (BSD or MIT) so
the work can be included in the BSD family of operating systems as well as
Linux?

~~~
zx2c4
I answered this question elsewhere. The answer is that - probably, why not? I
need to think about it for more than a few seconds. But the only reason I
chose GPLv2 is because that's what Linux uses. I'll quit being lazy and think
more carefully about licenses, and hopefully we'll wind up with something good
for the BSDs.

~~~
pdimitar
I am not a lawyer but in my eyes having a BSD/MIT license will also save you
from a corporation "adopting" your technology and sue you afterwards for
infringing a super vague patent of theirs... or something along the lines.

If your work is in the public domain, then at least the corporations would
have _much_ harder time hijacking and wall-garden it, and the chances of them
simply giving up are higher. Or so I hope.

I've read a good chunk of your website. GREAT WORK! Do not give up, you're
doing next-level work. =)

~~~
loeg
Yeah, you're not a lawyer. This is nonsensical gibberish.

~~~
pdimitar
The corporations haven't really left us with good impressions in the last 15
years though, did they?

If I learned anything from those last 15 years is that they'll sue you if you
don't agree the Moon is made of cheese if it suits their agenda.

So I remain cynical towards them. If they can hijack a good technology for
their own profit, they will do it. I think we all knew that much at this
point?

------
hueving
Why is this in the kernel? It seems to me like a failed separation of concerns
compared to running this in userspace. There shouldnt be anything magical
requiring this level of coupling.

~~~
zx2c4
Because it's necessary for any reasonable performance. If you're concerned
about this, you might have several heart attacks when you look at the obscene
amount of code that IPsec has in the kernel. IPsec is the only other
alternative for high speed VPNs, and it's frighteningly complex, both in
deployment and in codebase.

WireGuard, on the contrary, is around 4000 lines of core code. This is super
short, and allows for a single individual to audit it. By focusing on
simplicity and ease-of-auditability, I hope to achieve something that can be
considered secure.

Compare this to the massive codebase of OpenVPN/OpenSSL and the various other
userspace (read: slow as mollasses) VPNs. WireGuard is considerably shorter
and simpler than those too.

Also, keep in mind that on Linux, jumping from userspace to ring0 execution
isn't exactly difficult. So in practice I'm not sure it matters.

I make a living by exploiting kernels. This makes me very aware of the
questions associated with running this in the kernel. I've tried to write
WireGuard using my experience breaking similar codebases; WireGuard is short
enough that it should receive the thorough attention that this sort of
software deserves. By focusing on simplicity, I think we can in time achieve
something quite trustworthy.

Finally, there will be a (necessarily lower speed) cross platform
implementation released that's written in Rust. At the end of the day I
suspect that all parties will find themselves pleased.

~~~
q3k
> Because it's necessary for any reasonable performance.

This is simply not true [1] [2].

[1] - [http://dpdk.org/](http://dpdk.org/)

[2] -
[http://info.iet.unipi.it/~luigi/netmap/](http://info.iet.unipi.it/~luigi/netmap/)

~~~
zx2c4
I love DPDK. Super fun. I've actually made a few projects with it. But this is
for creating closed network systems, not for integrating into Linux's
networking infrastructure. If somebody would like to produce a WireGuard
implementation (library, I guess) for DPDK, I'd be super happy about this, and
I'm sure it'd find some specialized users. But for everything else, there's
the ordinary design.

~~~
q3k
It is absolutely possible to create DPDK applications that send/receive data
into the Linux network stack using KNI [1]. I'm not sure if I'm qualified to
say whether DPDK is “for” something, but the means to achieve this exist.

[1] -
[http://dpdk.org/doc/guides-16.04/prog_guide/kernel_nic_inter...](http://dpdk.org/doc/guides-16.04/prog_guide/kernel_nic_interface.html)

------
teddyh
Note: This project, despite having the text of the GPL 2 in a file named
“COPYING”, is not actually licenced under GPL 2. The actual copyright
statement found in source files is “ _Copyright 2015-2016 Jason A. Donenfeld
<Jason@zx2c4.com>. All Rights Reserved._”. It does not reference the GPL. This
means, legally, that nobody can do anything with it.

If the author actually meant to licence it under the GPL 2, he should read and
follow the instructions in the GPL itself, more specifically the section at
the end titled “ _How to Apply These Terms to Your New Programs_ ”.

~~~
icebraining
That may technically be true, but if the author was to sue anyone based on
that argument, this project itself would be in violation of copyright law,
since all the code seems to be distributed only as a Linux kernel module (with
all files #including kernel headers and such) and so it actually _has_ to be
distributed under the GPLv2.

~~~
teddyh
This is true, but I imagine that no company will actually use or distribute
this project in any way, since it is actually illegal (however technically)
for them to do so until this issue is resolved.

------
ksec
I know asking for MIT / BSD or Apache 2 may be a little bit of stretch.

But any chance of LGPL? Or would we need a conplete reimplementation for BSD?

~~~
zx2c4
I don't really have any problem re-licensing it less restrictively, I don't
think. I'll have to think about it for more than 10 seconds I suppose. But I
put "GPLv2" there without much thought simply because that's what Linux uses.
But you make a good point about the BSDs.

~~~
PeCaN
As a hardcore BSD user, GPLv2 is perfectly fine with the BSDs. They all ship
with GPLv2 software by default.

FreeBSD doesn't like GPLv3, but OpenBSD and DragonFlyBSD don't have a problem
with it. I don't know about NetBSD off the top of my head.

IMO this seems like something that should be GPL and I think you needn't
change it.

~~~
loeg
FreeBSD has a moratorium on importing new GPL code to base, and especially the
kernel.

------
asymmetric
Just wanted to point out that the author is also behind the excellent password
manager pass:
[https://www.passwordstore.org/](https://www.passwordstore.org/).

Congratulations.

~~~
ronnier
That's a very nice tool, but I dislike how it leaks information via the
visible directory structure and filenames.

------
amluto
A couple questions:

How do you deal with MTU? OpenVPN's handing is particularly bad [1]?

Is the whole protocol in-kernel or just the data plane?

For admins who want to provision large number of clients, do you ever plan to
implement some kind of certificate hierarchy?

[1]
[https://community.openvpn.net/openvpn/ticket/375](https://community.openvpn.net/openvpn/ticket/375)

~~~
zx2c4
> How do you deal with MTU? OpenVPN's handing is particularly bad [1]?

MTU is dealt with the same way as other kernel space tunneling devices.

> Is the whole protocol in-kernel or just the data plane?

All of it, which is why there's so much emphasis on simplicity.

> For admins who want to provision large number of clients, do you ever plan
> to implement some kind of certificate hierarchy?

Rather, the goal is to make the kernel interface very simple and minimal, so
that admins can then glue ontop whatever situation they want. This could be
certificates, or pigeons, but the important thing is that it's a layer ontop
(in userspace), and not intimately bound to the core.

~~~
clinta
Are there currently methods where unknown public keys are passed to a
userspace application to be verified? Or is this something that will be
implemented in the future?

------
Aissen
Paper:
[https://www.wireguard.io/papers/wireguard.pdf](https://www.wireguard.io/papers/wireguard.pdf)

------
vonnyfly
Do you have try this in China internet? As we know, China has a more
complicated network. UDP packets have a large loss.

If it could work better than ocserv, this vpn will be a milestone.

~~~
alainchabat
same question here

------
nikolay
Is there a way to connect from macOS to the VPN?

~~~
zx2c4
As mentioned in the roadmap and the cross-platform page, we're working on a
cross-platform userspace client, so Mac and Windows users can use it too. It's
in the works!

~~~
cakoose
This comment was marked 'dead', but I think it was a useful question (though
maybe a little aggressive in its wording):

> So what's the point ? Linux is a niche market. Mac & Windows will be the
> vast majority of your users and won't enjoy your killer kernel-based
> feature...

Even when Windows/Mac are the vast majority of clients, each client only needs
to process its own traffic. The VPN gateway is more likely the bottleneck,
since it needs to process everyone's traffic. There are many organizations
that would have no problem running Linux on the VPN gateway and could reap the
benefits.

Also, the Linux in-kernel implementation is just the first(?) thing being
released. WireGuard is a VPN protocol and its killer feature is good security
that's simple enough to implement in 4000 lines of code. This simplicity makes
it easier for someone to write a Windows/Mac kernel driver.

~~~
atonse
What's incredible is that the Go implementation is something like 100 lines.

~~~
madeddie
Not sure if you were being sarcastic ;) but the code in 'external-tests' is
just that: tests.

It makes a UDP connection, it sends and receives some packets and then exits
again. It's by no means a functional VPN, just the handshake.

No doubt it'll grow into an actual client, but don't be too amazed by it just
yet :D

------
Retr0spectrum
Can someone explain why being in-kernel is considered a feature?

~~~
artie_effim
So, everyone needs to take a deep breath here. In kernel VPN is giving me a
bit of a security heart attack. As a security professional I would recommend
not running this on anything but a sandbox that isn't connected to your
environment. A single misstep in the code, a bad implementation of a crypto
library or a bad hook could easily lead to ring 0 compromise.

Not trying to discount the author's work, and I haven't reviewed any of the
documentation, but until this gets evaluated by a CC lab (or like independent
group) I would not implement in anything you care about.

~~~
tptacek
As a "security professional", I kind of don't care whether this is in-kernel
or not.

First, this is Linux, and if someone manages to get code execution in your
unprivileged userland program, the odds of you keeping them out of your kernel
are already pretty low.

Second, and more importantly, _this is VPN software_. If your VPN gets popped,
you probably have bigger problems than whether the attacker got the kernel on
the VPN server, as opposed to just being able to create arbitrary network
connections from the "inside" of the VPN.

If you don't want to run it, don't run it. If you're going to ask me whether
I'd trust OpenVPN more than WireGuard, no, I do not.

~~~
Retr0spectrum

        "If someone manages to get code execution in your
        unprivileged userland program, the odds of you keeping
        them out of your kernel are already pretty low."
    

Could you provide some sources/examples for this?

~~~
tptacek
Start here:

[https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-
ROP.p...](https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.pdf)

Are you running the grsecurity patches? If not, everything they do that your
kernel doesn't do is another reason your userland will inevitably cough your
kernel up to an attacker at some point. Even with those patches, it's still an
inevitability; it's just that interval is longer.

I don't run them! I do something easier: I assume that if I lose control of
userland on a Linux machine, I've lost the whole box.

It is especially weird, though, to see security people engaging in this kind
of risk reasoning. It seems to me that most of the times you lose code
execution _on your VPN server_ , the kernel security of the VPN server is
pretty far down the list of problems you need to deal with.

------
throwanem
Looks awesome! I can't wait to play with it when it hits 1.0.

In advance of that, I'm curious: What's the tl;dr: on how this compares to
Tinc? In particular, I'm wondering what WireGuard's mobile story looks like,
especially in comparison with Tinc's (which is pretty rudimentary as far as I
can tell), and about the extent of effort that's likely to be involved in
ongoing configuration management.

~~~
zx2c4
Faster, more secure, and works quite well with mobile thanks to built-in
roaming.

------
bulatb
What happens if a client gets assigned a new IP that isn't in the server's
whitelist? How do they connect?

~~~
zx2c4
Endpoint IPs are learned based on successfully authenticated/decrypted
packets. The Endpoint= entry in the config is just the location of an initial
server endpoint. Inner tunnel IPs are fixed in the config, and it's up to
things that build ontop of WireGuard to manage this however fits best.

------
dmitrygr
""Encrypt entire IP packet using peer ABCDEFGH's public key.""

Really?

1\. RSA & ECC are both too slow for this to be performant

2\. Padding???

Certainly you meant "encrypt using a negotiated symmetric key". And earlier
you meant to say "negotiate symmetric key with peer"

~~~
zx2c4
Your concern (1) is valid, but fortunately that's an over-simplification in
the casual introduction part of documentation, which I'll fix. Sorry about
that. This should read more like, "Encrypt entire IP packet using the
symmetric session associated with peer ABCDEFGH." Thanks for pointing this
out. As for (2), WireGuard indeed does padding; see the protocol page or the
paper for details.

~~~
dmitrygr
My concern is alleviated

Thanks!

------
maxhou
Does the protocol implement any kind of negotiation (ciphers, ...) ? if not,
how would you handle future type of attacks against the then hardwired
constructions ?

I fully agreed that being in-kernel is the right choice for performance, but
the chosen constructs excludes the possibility of using any type of existing
crypto hardware accelerator that shines in the IPSEC use-case (cache cold data
== no cache flush overhead, fully async processing of packets with DMA
chaining). Time to start lobbying SOC vendors :)

~~~
zx2c4
The cipher suite is part of the Noise preamble, so all operations are
crytographically bound to the cipher suite to prevent against related-algo
attacks. WireGuard itself has no plans for cipher agility, something that is
considered an anti-feature. If these ciphers are ever considered problematic,
we'll change them and release a new version (with an incremented preamble),
and the new set of ciphers will be similarly non-configurable.

Fortunately AVX2-accelerated (and soon AVX512-accelerated) ChaPoly is super
fast in pretty much all hardware.

------
amq
Performance comparison would be welcome, especially on low-end hardware. For
example, I'm getting 12 Mbps with OpenVPN BF-CBC on AR9341, I wonder what
could WireGuard achieve.

~~~
zx2c4
I think I have this board laying around actually. A friend is working on
OpenWRT packages so some benchmarking on there should be around the corner.

------
Anonionman
It would be useful to have option to connect to VPN server trough SOCKS/HTTP
proxy like you can do with OpenVPN, and it is useful for traffic obfuscation
and combining VPN with Tor/I2P. Another thing that I like is XOR patch for
OpenVPN
([https://github.com/clayface/openvpn_xorpatch](https://github.com/clayface/openvpn_xorpatch)),
that can be very useful in hiding you are connecting to VPN.

------
wmf
I'm surprised to see that ChaCha-Poly is faster than hardware-accelerated AES-
GCM. Any ideas why?

------
wargame
Is it possible to use TCP-only?

~~~
zx2c4
WireGuard is UDP only. For TCP or SSL tunneling, look at a million other
things that already do this.

~~~
cakoose
(I don't know much about networking.)

What are the advantages of doing UDP instead of IP?

It seems like, all else being equal, doing IP has the advantage of working
with UDP and TCP out of the box.

~~~
beagle3
It transfers general IP packets, but encapsulates them inside UDP packets.

------
naasking
Seems like an interesting project. How does it compare to zerotier:

[https://www.zerotier.com/](https://www.zerotier.com/)

~~~
nickpsecurity
I was going to ask that myself but ZeroTier provided a hint. It seems to be
aiming for more than a simple, IPsec replacement. It will have more features
and complexity no matter what. Also, Jason already speced out the WireGuard
protocol plus intends a Rust port. Will significantly increase code-level
security over ZeroTier. Both need strong, peer review at protocol and
implementation levels, though. As always with these things.

~~~
api
Designer/developer of ZeroTier here. :)

Yes, our goals are much broader than VPN. You can think of ZeroTier as a
virtual smart switch built on a P2P network; a "smart switch for Earth." We
want to totally abstract away the physical network. A lot of ZT's complexity
over WireGuard is about working around the underlying network (NAT-t, dual-
stack support, dealing with timeouts and path failures, relay fallback, peer
location and roaming, redundancy, etc.) as well as smart switch features and
robustness against DOS attacks and similar things.

Nevertheless ZT's core code really isn't _that_ big. The core protocol
implementation is 23,000 lines of C++ code. This includes many very long
comments documenting the protocol, etc., so total lines of actual code is
probably more like 18-20k. It's comparable to an embedded TCP stack.

WireGuard does have some things in common with ZeroTier, such as the use of
cryptography to identify endpoints and eliminate the hard-coding of endpoint
addresses. This is one of many ways that IMHO cryptography actually simplifies
networking. I really like the WireGuard design in general and I think it has a
somewhat different use case from ZeroTier, namely fast long-lived provisioned
links across WANs and insecure LANs. You could use ZT for that but this being
in-kernel makes it likely faster. In any case I hate IPSec (over-engineered
mess, terribly hard to configure) so any alternative to that is welcome.

(Edit: there _are_ things you can do to speed up user-mode networking like
zero-copy data paths, etc., so it's not guaranteed that this would always be
faster. But that's another topic.)

------
felixding
Does it work against Deep Packet Inspection? I live in China, most popular VPN
protocols can't pass through the great firewall.

Sorry for my English.

------
eximius
Please let me know if this has already been posted.

Is there any worry that someon might perform a DoS attack against a client by
replaying a valid packet from the target from different hosts so that the
other servers cannot correctly route to the real IP of the target? This is
based solely off of the description on the homepage and it might not be
possible due to implementation details I'm unaware of.

~~~
zx2c4
Replay attacks don't work because of the nonce, so that's handled
successfully.

But an attacker with an _active_ man in the middle position might change the
outer (unencrypted) src IP of a packet. However, that src will need to be able
to produce authentic replies; otherwise the session will quickly be deemed
invalid, so that mitigates any potential very oddball amplification attacks
you could dream up. And regardless, an attacker with this kind of active man
in the middle can already drop packets at will, so this isn't a vulnerability.

------
tw04
Why would I want this over softether?

------
maffblaster
Nice work! Exciting!!

------
lawnchair_larry
You don't want this in the kernel.

