Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WireGuard: Next Generation Secure Kernel Network Tunnel

fosdem.org

Post reply on HN
Print view View original

31–40 of 44 posts

Re: WireGuard: Next Generation Secure Kernel Network Tunnel

#31

Post by baby »

XorNot wrote: post #22
baby wrote: post #21

Earlier quoted context omitted.

> but exchanging SSH public keys is actually a huge logistical hassle which scales very poorly. 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.

Well that's the thing: SSH has recently gained support for signed public keys - i.e. x.509 style certificate authorities. Outside of that you have things like monkeysphere doing the same with GPG, or simpler things like LDAP scripts which just check the key against LDAP (Hashicorp Vault does something similar). But it's why I'm skeptical the UI is substantially improved: the simplest UI for VPN tends to be pre-shared…

> the simplest UI for VPN tends to be pre-shared keys

that's what wireguard is doing.

Re: WireGuard: Next Generation Secure Kernel Network Tunnel

#33

Post by aseipp »

baby wrote: post #31
XorNot wrote: post #22

Earlier quoted context omitted.

Well that's the thing: SSH has recently gained support for signed public keys - i.e. x.509 style certificate authorities. Outside of that you have things like monkeysphere doing the same with GPG, or simpler things like LDAP scripts which just check the key against LDAP (Hashicorp Vault does something similar). But it's why I'm skeptical the UI is substantially improved: the simplest UI for VPN tends to be pre-shared…

> the simplest UI for VPN tends to be pre-shared keys that's what wireguard is doing.

I believe they meant to say "symmetric key without any public key exchange protocol", e.g. like spiped, more than SSH. ("Pre-shared" is a bit more confusing in this particular context, admittedly.)

Re: WireGuard: Next Generation Secure Kernel Network Tunnel

#34

Post by baby »

aseipp wrote: post #33
baby wrote: post #31

Earlier quoted context omitted.

> the simplest UI for VPN tends to be pre-shared keys that's what wireguard is doing.

I believe they meant to say "symmetric key without any public key exchange protocol", e.g. like spiped, more than SSH. ("Pre-shared" is a bit more confusing in this particular context, admittedly.)

Oh ok. Yeah sure it makes the protocol simpler. You lose a bunch of security properties though (forward secrecy on the top of my head).

Re: WireGuard: Next Generation Secure Kernel Network Tunnel

#35

Post by cakeface »

sargun wrote: post #7
lgierth wrote: post #5

Earlier quoted context omitted.

I'm less worried about that because it's so small. WireGuard is ~4k LOC -- thus measurably less complicated than OpenVPN (~100k LOC + OpenSSL), StrongSwan (~410k), or SoftEther (~330k). 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…

Yeah, but BPF can operate in kernel space directly on SKBs. If you look at the XDP work, there's a lot of promise. In fact I've implemented ECC in BPF -- other than the state, and negotiation components, I don't see why this can't adapt BPF.

This comment seems interesting! Unfortunately I have no idea what you are saying. Can you unpack the acronyms for me?

Re: WireGuard: Next Generation Secure Kernel Network Tunnel

#36

Post by sargun »

foobiekr wrote: post #23
sargun wrote: post #7

Earlier quoted context omitted.

Yeah, but BPF can operate in kernel space directly on SKBs. If you look at the XDP work, there's a lot of promise. In fact I've implemented ECC in BPF -- other than the state, and negotiation components, I don't see why this can't adapt BPF.

Trireme?

What?

Re: WireGuard: Next Generation Secure Kernel Network Tunnel

#37

Post by sargun »

xorcist wrote: post #12
sargun wrote: post #7

Earlier quoted context omitted.

Yeah, but BPF can operate in kernel space directly on SKBs. If you look at the XDP work, there's a lot of promise. In fact I've implemented ECC in BPF -- other than the state, and negotiation components, I don't see why this can't adapt BPF.

That sounds crazy! Was it just for fun or is there a use case? What's performance like?

This was actually around the time that WireGuard initially announced. We had a product that we ship on-prem that needs end-to-end security guarantees. Unfortunately, IPSec has a bunch of issues around IKE and maintaining sanity at a medium node count.

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.

Re: WireGuard: Next Generation Secure Kernel Network Tunnel

#38

Post by sargun »

cakeface wrote: post #35
sargun wrote: post #7

Earlier quoted context omitted.

Yeah, but BPF can operate in kernel space directly on SKBs. If you look at the XDP work, there's a lot of promise. In fact I've implemented ECC in BPF -- other than the state, and negotiation components, I don't see why this can't adapt BPF.

This comment seems interesting! Unfortunately I have no idea what you are saying. Can you unpack the acronyms for me?

Sorry! Once you get deep enough in this tech, you seem to have more in common with an alien language than actual common English.

* 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.

Re: WireGuard: Next Generation Secure Kernel Network Tunnel

#39

Post by sargun »

tptacek wrote: post #28
sargun wrote: post #7

Earlier quoted context omitted.

Yeah, but BPF can operate in kernel space directly on SKBs. If you look at the XDP work, there's a lot of promise. In fact I've implemented ECC in BPF -- other than the state, and negotiation components, I don't see why this can't adapt BPF.

You implemented an elliptic curve scalar multiplication in BPF bytecode? Why? Which curve?

So, for one of the implementations, yes, we implemented Curve25519 inside of the Kernel. Basically, every node was pushed into a map with the association of IP/Port to key data.

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?

Re: WireGuard: Next Generation Secure Kernel Network Tunnel

#40

Post by sargun »

zx2c4 wrote: post #17
sargun wrote: post #7

Earlier quoted context omitted.

Yeah, but BPF can operate in kernel space directly on SKBs. If you look at the XDP work, there's a lot of promise. In fact I've implemented ECC in BPF -- other than the state, and negotiation components, I don't see why this can't adapt BPF.

Sidechannel free? High performance? Multi core? I'd love to see this. Sounds really interesting. What curve? Got source?

Sidechannel free - Curve25519 is meant to be resistant to side channel attacks. We didn't spend much time seeing if the actual cryptographic code was secure.

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.

Post reply on HN