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

21–30 of 44 posts

Re: WireGuard: Next Generation Secure Kernel Network Tunnel

#21

Post by baby »

XorNot wrote: post #3

It's not clear to me that this really solves any of the UI and management problems associated with VPNs. I'm sure the new crypto-design is interesting, but exchanging SSH public keys is actually a huge logistical hassle which scales very poorly. 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…

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

Re: WireGuard: Next Generation Secure Kernel Network Tunnel

#22

Post by XorNot »

baby wrote: post #21
XorNot wrote: post #3

It's not clear to me that this really solves any of the UI and management problems associated with VPNs. I'm sure the new crypto-design is interesting, but exchanging SSH public keys is actually a huge logistical hassle which scales very poorly. 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…

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

Re: WireGuard: Next Generation Secure Kernel Network Tunnel

#23

Post by foobiekr »

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.

Trireme?

Re: WireGuard: Next Generation Secure Kernel Network Tunnel

#24

Post by foobiekr »

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.

Trireme?

Re: WireGuard: Next Generation Secure Kernel Network Tunnel

#25

Post by xorcist »

nl wrote: post #9

Speaking of VPNs.... 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 w…

Set a tag based on the uid with iptables (set-mark), then set up a separate routing table (ip rule .. fwmark ..) for those packets. It's always a good idea to run application with a unique id to set ulimit anyway, even if you can identify traffic by other means (such as source ports). These things are well covered in the Advanced Routing Howto available at lartc.org.

Re: WireGuard: Next Generation Secure Kernel Network Tunnel

#26

Post by zokier »

kijiki wrote: post #13
nl wrote: post #9

Speaking of VPNs.... 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 w…

Namespacing would work, but it might be simpler to use multiple routing tables and "ip rule" to match each app and direct it to the right routing table. You can use iptables to match on the process and set a mark on the packet that "ip rule" will match on.

Shouldn't namespacing be just 'ip netns add wireguard && ip link set dev wg0 netns wireguard && ip netns exec wireguard '? Seems simple enough.

Re: WireGuard: Next Generation Secure Kernel Network Tunnel

#27

Post by tptacek »

dguido wrote: post #4

If you want a reliable VPN you can use today on nearly every platform, try Algo VPN. It uses simplifies using IPSEC so that anyone who can run a few command line scripts can use it. 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 like Algo a lot, but find it approximately as hard to recommend an IPSEC head-end to a sensitive network as I do recommending OpenVPN, and OpenVPN has better clients. Algo makes sense to me as the kind of VPN I set up to run traffic through when I travel, but not for protecting networks.

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.

Re: WireGuard: Next Generation Secure Kernel Network Tunnel

#28

Post by tptacek »

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.

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

Re: WireGuard: Next Generation Secure Kernel Network Tunnel

#29

Post by mschuster91 »

wallace_f wrote: post #16
nl wrote: post #9

Speaking of VPNs.... 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 w…

Out of curiosity, what's the use case for this?

For example, to limit a browser process from connecting to anything except the TOR proxy.

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.

Re: WireGuard: Next Generation Secure Kernel Network Tunnel

#30

Post by netvarun »

nl wrote: post #9

Speaking of VPNs.... 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 w…

There was a shown hn about 3 months ago for a project somewhat similar to what you are describing - https://news.ycombinator.com/item?id=12848917
Post reply on HN