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

WireGuard: next generation in-kernel modern VPN

wireguard.io

Post reply on HN
Print view View original

111–120 of 157 posts

Re: WireGuard: next generation in-kernel modern VPN

#111

Post by viraptor »

comex wrote: post #95
tptacek wrote: post #43

Earlier quoted context omitted.

Severe performance impact. Since we appear to be bolted to the top of the thread, I'll repeat a point I buried deeper in the thread: Maybe some readers of this thread are in the habit of casually bringing up random VPN connections between individual Linux machines. But in my experience, people tend to invest in VPN configurations so they can connect developers and ops to deployment environments and company networks.…

Who said anything about VPN server ? The client is running the same code; what if it's popped? > But in my experience, people tend to invest in VPN configurations so they can connect developers and ops to deployment environments and company networks. That's like, the big use case for serious VPNs. You're missing the other big use case: VPNs used to get one's internet access through a different network, in order to ev…

You seem to talk about a completely different use of VPN. The "VPN server you route all internet access through" is a glorified encrypting web proxy. There's no "server" in WireGuard as far as I can tell - it's only peers which expose whole networks behind them. Both use cases call for very different solutions: The corporate-style VPN protects your networks and remote endpoints from someone random connecting to them. The glorified web-proxy style VPN needs to mainly encrypt all the outgoing traffic.

I doubt WG is a real candidate for the case you're talking about.

Re: WireGuard: next generation in-kernel modern VPN

#112

Post by viraptor »

nickpsecurity wrote: post #87
tptacek wrote: post #82

Earlier quoted context omitted.

It's Linux kernel resident. It's C code.

Wow. Talk about overlooking the obvious. Thanks lol...

Maybe most likely, but not necessarily obvious. While there's no popular module for kernel written in something else than C (as far as I know), there are known ways to write working non-C modules.

Re: WireGuard: next generation in-kernel modern VPN

#113

Post by loeg »

zx2c4 wrote: post #97
loeg wrote: post #70

Earlier quoted context omitted.

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?

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.

Thanks for considering it! For what it's worth, there is dual BSD/GPL precedent in various places in Linux (e.g., most of the drm GPU drivers, NTB, etc).

Re: WireGuard: next generation in-kernel modern VPN

#114

Post by zx2c4 »

dfrey wrote: post #90
zx2c4 wrote: post #22

Earlier quoted context omitted.

> Does the server get a separate wg interface for every client that connects? No. Each wg interface has a public/private key. It then has a list of peers' public keys and associated allowed IPs. By tying each public key to the allowed IPs of that public key, you can be sure that if a packet comes from wg0 and comes from a particular src IP, it comes from who you want. So no need for a new wg0 for each peer. > Does th…

>> Does the server get a separate wg interface for every client that connects? > No. Each wg interface has a public/private key. It then has a list of peers' public keys and associated allowed IPs. By tying each public key to the allowed IPs of that public key, you can be sure that if a packet comes from wg0 and comes from a particular src IP, it comes from who you want. So no need for a new wg0 for each peer. Does t…

The client is identified by the public key only. Two clients behind the same NAT can connect to the same server, no problemo.

Re: WireGuard: next generation in-kernel modern VPN

#115

Post by code_research »

dmix wrote: post #59
tptacek wrote: post #43

Earlier quoted context omitted.

Severe performance impact. Since we appear to be bolted to the top of the thread, I'll repeat a point I buried deeper in the thread: Maybe some readers of this thread are in the habit of casually bringing up random VPN connections between individual Linux machines. But in my experience, people tend to invest in VPN configurations so they can connect developers and ops to deployment environments and company networks.…

And getting from userspace -> kernel doesn't pose much of a challenge for attackers. Especially on stock Ubuntu machines that are so popular. You could probably even find priv esc exploits on github/blogs for a good chunk of VPS servers. I did that when I forgot a root password on a yr old machine recently.

Interesting! Would you please like to post some links to actual privilege escalation code for a stock Ubuntu 16.04 - thank you very much for your attention!

Re: WireGuard: next generation in-kernel modern VPN

#116

Post by atonse »

cakoose wrote: post #93
zx2c4 wrote: post #24

Earlier quoted context omitted.

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!

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 bot…

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

Re: WireGuard: next generation in-kernel modern VPN

#117

Post by comex »

viraptor wrote: post #111
comex wrote: post #95

Earlier quoted context omitted.

Who said anything about VPN server ? The client is running the same code; what if it's popped? > But in my experience, people tend to invest in VPN configurations so they can connect developers and ops to deployment environments and company networks. That's like, the big use case for serious VPNs. You're missing the other big use case: VPNs used to get one's internet access through a different network, in order to ev…

You seem to talk about a completely different use of VPN. The "VPN server you route all internet access through" is a glorified encrypting web proxy. There's no "server" in WireGuard as far as I can tell - it's only peers which expose whole networks behind them. Both use cases call for very different solutions: The corporate-style VPN protects your networks and remote endpoints from someone random connecting to them.…

It's very common to use existing VPN protocols for proxying - Google "VPN" and you'll find many commercial services. And the WireGuard white paper mentions passing all traffic to a single peer as a possible configuration, so I think it should be usable for it as well, modulo OS compatibility. Which is good, because existing VPN software suffers from the same configuration and security headaches whether it's used for proxying or corporate networks, and non-VPN proxies are an inadequate solution.

Web proxies are suboptimal because they only work with web traffic, or even if you use HTTP CONNECT, only TCP. SOCKS is mildly better at a protocol level, with SOCKS5 supporting both TCP and UDP, but still suboptimal if the server end is able to give each client its own IP address (not so common with IPv4 but easy with IPv6), due to the existence of protocols other than TCP and UDP. More importantly in practice, SOCKS clients are typically implemented in userland rather than the kernel, so each individual application needs to be configured to use the tunnel. There is software that lets you use any program with SOCKS by hooking socket API calls, but that's essentially a hack, and has many practical issues. Much nicer to just have the tunnel as a network interface like any other, and let the kernel's network stack work as it was designed - which is usually done with VPN software. VPN also lets one host transparently handle proxying for another, e.g. a router for a home network, or the host in the VM setup I mentioned in my original post.

Re: WireGuard: next generation in-kernel modern VPN

#118

Post by uudecode »

tptacek wrote: post #76
teacup50 wrote: post #65

Earlier quoted context omitted.

What do you want me to say? I'd think it ought to be self-evident that greater risks exist when operating in a single shared memory space at ring 0. If nothing else, the trampoline to privilege is already complete; very little stands between a vulnerability and an active exploit. The end goal ought to be getting more things out-of-ring 0, not adding more things to it -- I'm never going to say that "I'm not concerned"…

I addressed CPL0 vs CPL3 elsewhere on the thread. All things are not equal here. OpenVPN uses TLS. The whole point of WireGuard is to shake off that complex baggage.

It's possible to shake off OpenVPN and TLS without shaking off use of tun/tap. I use a tun/tap based "VPN" (overlay) and I quite like it. One could even add NaCl to it if they were so inclined.

I sometimes think Apple removed /dev/tap from iOS because it provided too much potential freedom.

Not every user needs in-kernel performance for their daily routine but there's certainly an argument that every user could use a decent "VPN" that could run on all their computers.

Alas, OpenVPN mindshare is rather strong, to the detriment of existing or future userspace alternatives.

Re: WireGuard: next generation in-kernel modern VPN

#119

Post by viraptor »

comex wrote: post #117
viraptor wrote: post #111

Earlier quoted context omitted.

You seem to talk about a completely different use of VPN. The "VPN server you route all internet access through" is a glorified encrypting web proxy. There's no "server" in WireGuard as far as I can tell - it's only peers which expose whole networks behind them. Both use cases call for very different solutions: The corporate-style VPN protects your networks and remote endpoints from someone random connecting to them.…

It's very common to use existing VPN protocols for proxying - Google "VPN" and you'll find many commercial services. And the WireGuard white paper mentions passing all traffic to a single peer as a possible configuration, so I think it should be usable for it as well, modulo OS compatibility. Which is good, because existing VPN software suffers from the same configuration and security headaches whether it's used for…

I think you missed my point. Sure, every VPN solution can be turned into "proxy all internet traffic through there" with enough configuration. What I meant is that tptacek was talking about commercial/serious VPN as in corporate usage, not commercial as in "it takes money from anyone".

You're talking about two completely different use cases with very different goals and potential issues.

Post reply on HN