Does the server get a separate wg interface for every client that connects? Or does it do something like multipoint GRE interfaces with next hop addresses in the arp table?
Does this do a DH key agreement to guarantee forward secrecy or does it literally encrypt the packet with the peers public key?
Also is it in the scope of this project for peers to discover each other for direct communication, like a Phase3 DMVPN?
Hey! Knew I recognized that username. You also make pass which I've been using since you released that too. Definitely going to give this a run. Thanks for more useful tools!
Don't have time for a detailed review. However, I like that you're working to replace IPsec with something simpler, easier to use, and with flexible deployment. Crypto algorithms look better than most VPN's I see as well. Good work on all that. Just remember to aid others' verification efforts later on by keeping it modular, minimal shared state, simple constructions in code, and so on. Whatever passes through a decent static analysis tool.
Also, one of easiest, formal methods is Design by Contract which can be emulated with asserts for pre- and post-conditions plus main invariants. Quite useful to encode operating assumptions in there. Such can also be used for automating test-case generation, fuzzing, dynamic analysis, and covert channel analysis. Oh yeah, definitely do a covert channel analysis on anything that gets near the keys to plug any leaks.
This looks interesting and I will be sure to check it out when I get the chance. I see from the examples on the site that it's IPv4 everywhre. Is there IPv6 support ? If not, is it on the roadmap ?
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.
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 <[email protected]>. 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”.
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.
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.
> 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.
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!
It's not possible to do highspeed crypto from userspace while still integrating with the usual networking stack. Tun devices result in copies and context switches which makes things quite slow.
This also adds quite a bit of simplicity.
But sure, I agree, it's scary. But not nearly as scary as the obscenely huge xfrm/ipsec layer in the kernel. Or the dozens of other kernel tunneling deivces available. And I dare even say it's not as scary as most userspace VPN solutions like OpenVPN which are massive code bases. WireGuard, in contrast, aims to be quite minimal in its codebase, so that it can be audited by an individual.
I didn't make the title of this HN post, unfortunately. But do note: there _will_ be userspace implementations of WireGuard. It's most certainly not tied to the kernel. It's just that the OP saw me present at a kernel conf about it. :P
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.
It's faster. Performance usually matters more than security for most "security" products. ;) Having extra code in kernel is usually just asking for it. Here's one done closer to high-assurance principles that I'm sure the WireGuard scheme could be ported to:
Far as keeping it in kernel, it might be implemented in SPARK and Rust to see if it gets through static and dynamic (if necessary) checkers. Test and fuzz it heavily. If C, use strong, static tools to show correctness and/or compiler transformations like SAFEcode (or Softbound+CETS) to immunize it. I know Criswell runs Linux kernel on SVA-OS with SAFEcode but not sure if S+CETS can do it. Such approaches will knock out most of the flaws that lead to code injection.
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.
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.
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.
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 :)
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.
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), that can be very useful in hiding you are connecting to VPN.
Similar cryptographic building blocks. WireGuard has an emphasis on no-negotiation, which it inherits from Noise, which is Trevor Perrin's well-regarded crypto protocol construction kit. As an application, WireGuard is _way_ simpler than ZeroTier; it's something you would build the remaining 90% of ZeroTier on top of.
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.
[+] [-] zx2c4|9 years ago|reply
I'm the author of this and would be happy to answer any questions you have.
[+] [-] clinta|9 years ago|reply
Does the server get a separate wg interface for every client that connects? Or does it do something like multipoint GRE interfaces with next hop addresses in the arp table?
Does this do a DH key agreement to guarantee forward secrecy or does it literally encrypt the packet with the peers public key?
Also is it in the scope of this project for peers to discover each other for direct communication, like a Phase3 DMVPN?
[+] [-] Aissen|9 years ago|reply
I'm curious what will be your strategy with regard to working or not with upstream Linux ?
[+] [-] piffey|9 years ago|reply
[+] [-] nickpsecurity|9 years ago|reply
Also, one of easiest, formal methods is Design by Contract which can be emulated with asserts for pre- and post-conditions plus main invariants. Quite useful to encode operating assumptions in there. Such can also be used for automating test-case generation, fuzzing, dynamic analysis, and covert channel analysis. Oh yeah, definitely do a covert channel analysis on anything that gets near the keys to plug any leaks.
[+] [-] marios|9 years ago|reply
This looks interesting and I will be sure to check it out when I get the chance. I see from the examples on the site that it's IPv4 everywhre. Is there IPv6 support ? If not, is it on the roadmap ?
[+] [-] nickysielicki|9 years ago|reply
One disadvantage off the bat is that every operating system from OSX to Windows 7 to Linux to *BSD already has support for IKEv2 and MOBIKE caked in.
[+] [-] ZoFreX|9 years ago|reply
[+] [-] rkeene2|9 years ago|reply
[+] [-] teacup50|9 years ago|reply
[+] [-] RRRA|9 years ago|reply
Couldn't it still be fast and written in a safer than C language considering the security context? (Or we'll still need to get grsec in there... :)
Cheers!
[+] [-] hueving|9 years ago|reply
[+] [-] teddyh|9 years ago|reply
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|9 years ago|reply
[+] [-] ksec|9 years ago|reply
But any chance of LGPL? Or would we need a conplete reimplementation for BSD?
[+] [-] zx2c4|9 years ago|reply
[+] [-] lasermike026|9 years ago|reply
[+] [-] asymmetric|9 years ago|reply
Congratulations.
[+] [-] ronnier|9 years ago|reply
[+] [-] amluto|9 years ago|reply
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
[+] [-] zx2c4|9 years ago|reply
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.
[+] [-] Aissen|9 years ago|reply
[+] [-] vonnyfly|9 years ago|reply
If it could work better than ocserv, this vpn will be a milestone.
[+] [-] alainchabat|9 years ago|reply
[+] [-] nikolay|9 years ago|reply
[+] [-] zx2c4|9 years ago|reply
[+] [-] Retr0spectrum|9 years ago|reply
[+] [-] zx2c4|9 years ago|reply
It's not possible to do highspeed crypto from userspace while still integrating with the usual networking stack. Tun devices result in copies and context switches which makes things quite slow.
This also adds quite a bit of simplicity.
But sure, I agree, it's scary. But not nearly as scary as the obscenely huge xfrm/ipsec layer in the kernel. Or the dozens of other kernel tunneling deivces available. And I dare even say it's not as scary as most userspace VPN solutions like OpenVPN which are massive code bases. WireGuard, in contrast, aims to be quite minimal in its codebase, so that it can be audited by an individual.
I didn't make the title of this HN post, unfortunately. But do note: there _will_ be userspace implementations of WireGuard. It's most certainly not tied to the kernel. It's just that the OP saw me present at a kernel conf about it. :P
[+] [-] artie_effim|9 years ago|reply
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.
[+] [-] nickpsecurity|9 years ago|reply
http://genode-labs.com/publications/mikro-sina-2005.pdf
Far as keeping it in kernel, it might be implemented in SPARK and Rust to see if it gets through static and dynamic (if necessary) checkers. Test and fuzz it heavily. If C, use strong, static tools to show correctness and/or compiler transformations like SAFEcode (or Softbound+CETS) to immunize it. I know Criswell runs Linux kernel on SVA-OS with SAFEcode but not sure if S+CETS can do it. Such approaches will knock out most of the flaws that lead to code injection.
[+] [-] throwanem|9 years ago|reply
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|9 years ago|reply
[+] [-] bulatb|9 years ago|reply
[+] [-] zx2c4|9 years ago|reply
[+] [-] dmitrygr|9 years ago|reply
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|9 years ago|reply
[+] [-] maxhou|9 years ago|reply
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 :)
[+] [-] amq|9 years ago|reply
[+] [-] Anonionman|9 years ago|reply
[+] [-] wmf|9 years ago|reply
[+] [-] wargame|9 years ago|reply
[+] [-] zx2c4|9 years ago|reply
[+] [-] naasking|9 years ago|reply
https://www.zerotier.com/
[+] [-] tptacek|9 years ago|reply
[+] [-] nickpsecurity|9 years ago|reply
[+] [-] felixding|9 years ago|reply
Sorry for my English.