WireGuard: Next Generation Secure Kernel Network Tunnel
fosdem.org
fosdem.org
Best of luck, Jason!
https://github.com/trailofbits/algo
It's great that someone is working on what comes next after IPSEC, but the platform support for everyone won't come any time soon. If you need a VPN today, Algo is your best answer.
I'm not convinced that the problem of replacing VPN protocols is so difficult that we should get comfortable with IPSEC. We're really just an OSX client away from WireGuard in the mainstream. And unlike IPSEC vs. OpenVPN, WG is clearly better than the alternative.
The core values of Algo are making self-hosting and initial setup easy and reliable.
I've recently started recommending it for a everyone who doesn't have IPsec hardware, something I should have done long ago (but I mistakenly thought it to be less thought out than it was). Android support is solid too.
> https://github.com/Nyr/openvpn-install
It automates the process of installing & creating OpenVPN, and means so that anyone who can download a file & run a bash file will be able to make a VPN.
The other thing is "container-ready" ... well it just isn't. I can use OpenVPN to do the same interface migration trick with a container today. That's not the challenge - the challenge is things like managing what happens when the VPN interface goes down and I need to recycle and reconfigure that interface (at which point you end up back at "allocate a private address space, stick the VPN container in a new address space, play with IPTables there to make sure losing the VPN routes doesn't mean you start routing over the regular NIC".
How do current solutions tackle this? It seems that at some point, if you want something to be two-way authenticated then you need to exchange some public keys.
But it's why I'm skeptical the UI is substantially improved: the simplest UI for VPN tends to be pre-shared keys - because everything more complicated simplifies to that interface "somehow everyone needs to agree who's allowed in" - and differs to SSH because SSH has more of a one-way contract "let this connection in, but I can't make the same connection back".
that's what wireguard is doing.
Is there a guide somewhere on how to partition applications on Linux so different apps use different VPNs?
Obviously the easier way is SSH SOCKS tunnels if the app supports it, but I'd like a more general method.
I believe it is possible by namespacing the apps (or I guess going all the way and containerizing them) and then setting the routing on a per-namespace basis.
Is there anywhere this is written down so I don't have to spent 6 hours trying to work out how to do it?
So:
>Is there anywhere this is written down so I don't have to spent 6 hours trying to work out how to do it?
Edit, I found https://freeaqingme.tweakblogs.net/blog/9340/netflix-using-a... which seems to cover at least some. It is done on a per-user basis though.
So, in case someone tries to de-anonymize you, unless the attacker has a kernel-level exploit, no packet will ever reach the attacker without going through TOR.
This could also be linked with a VM - so even if the attacker has a kernel-level exploit, there still won't be any outgoing packets.
Numbers taken from slide 5 of https://www.wireguard.io/talks/codeblue2016-slides-en.pdf
Moving to kernelspace brings it up to par with plain IP networking, minus a bit of overhead for the cryptographic operations. Userspace networking has overhead which is hard to overcome: context switching and CPU cache invalidation, copying packets between kernelspace and userspace, etc.
At the reception of a packet, if we didn't have a key, we'd punt the packet to userspace, asking it to do an exchange.
For some reason -- That I forget, we ended up putting the entire key into each packet. I think that when the "exchange" happened in userspace, we didn't actually store the entire box and key, instead we just generated an association specific key, and we wanted to be able to rotate this quickly. I think we just came up with the fact that doing the derivation was cheap enough that it'd be better to do it on every message.
What would then happen is that if we didn't have a box cached, we would calculate it, and this code was implemented as a helper function outside of the BPF itself. Then we did Poly1305 + XSalsa20 with a random nonce.
Why? Because IPSec is fucking complicated, and because I can?
In addition, using "pure" random nonces has all sorts of interesting problems.
Multicore - Yeah, we basically got that for free with BPF/XDP. It's kinda neat. You just load programs, and arrays get processes in parallel. We didn't have much state because we used random nonces, so there was no need for synchronization.
Unfortunately, the code will not be public because the project was closed source, it never shipped, and I'm no longer with the organization that paid for the work.
* BPF - Berkeley Packet Filter - BPF is a safe, in-kernel virtual machine that's meant to be able to introduce next generation functionality into the Kernel: https://lwn.net/Articles/603983/
* ECC - Elliptical Curve Encryption - Enough said
* XDP - eXpress Data Plane - This is a project atop BPF that's being merged into the Kernel to implement programmability features in the kernel, without requiring that people write crazypants code or unsafe code. It's backed, and used by Facebook. If you're familiar with Intel's DPDK, it's similar.
* SKB - Socket Buffers - These are the components that make up the data you send over the wire in the Kernel. When they come out of the kernel, they have to be flattened, and copied which is expensive. This is one of the biggest problems with usermode networking.
Our implementation was not..performant, hence why we abandoned it. Our thought was that we could make it work, but instead we ended up building our own key negotiation / management code atop some other stuff we had in order to setup the IPSec SAs.