TunSafe WireGuard Client for OS X | Hacker News Reader

TunSafe WireGuard Client for OS X

tunsafe.com

85 pointsludde43 comments

I've seen WireGuard recommended here pretty strongly, so I started looking into it, but I couldn't see exactly how it could replace OpenVPN for us.

We have an OpenVPN bastion for access into our VPC, and each engineer has their own key. When someone leaves, we can revoke their key.

But WireGuard seems to use a single key per network interface. Would we just create an interface for every engineer (I have no idea what the limits are on these - maybe they're cheap)? Or is this just not a good use case for WireGuard?

IIRC, the wireguard server's config file has defined peers (clients) so you could just remove the peer pubkey from the config file and they would no longer be able to connect.

With WireGuard you have one public/private key pair for that interface, and a list of public keys for trusted peers. Access management would still be about the same -- each engineer would have a key pair, and you'd have the public key on the trusted list of the host side.

> But WireGuard seems to use a single key per network interface.

Every interface is associated with a public/private key pair, but each interface need not peer with a single client. That would be inefficient. Instead, each peer (including clients and the server) generates a personal key pair when they configure their local WireGuard (e.g. wg0) interface. Afterwards they set up a local configuration file consisting of peers and respective public keys.

Then in the context of a company VPN, one peer is a designated server, and every other (client) peer lists the server’s remote IP as the only peer interface in their local configuration. The server has the public key of every client as respective entries in its local config file, which is used to restrict access to whitelisted clients. Any client with the corresponding private key locally can connect to the server’s interface using their local interface.

To remove a client from the white list, you simply remove their peer entry from the local config file on the server, much like how you remove an SSH public key from authorized_keys. In fact, a decent mental model for WireGuard is tuennling over SSH, but faster, leaner and with no option for a shell or password login.

Each network interface has a key pair associated with it, but it can pair with any number of other interfaces (having a pubkey for each). This is similar to how OpenVPN presumably works for you: each OpenVPN network device on your developers' laptops comes with a certificate they use to authenticate to you.

So yes: there's one interface per engineer laptop, but that's already the case. There's only one remote interface though. (Or several, if you want to have several VPNs -- Wireguard makes that pretty easy too!)

Here is some discussion about tunsafe.

https://lists.zx2c4.com/pipermail/wireguard/2018-March/00244...

That's not a "discussion", but a nasty spiteful post full of extreme, but baseless allegations.

That's not the whole story. There are further responses in that thread, including the opposing viewpoint from the TunSafe author.

* https://lists.zx2c4.com/pipermail/wireguard/2018-March/00246...

are the most relevant ones. (There are more, but they go slightly offtopic.)

Do I read it correctly that they banned @ludde from the wireguard IRC channel because his software wasn't open source? Damn.

Yes - that's what the WireGuard author did. I didn't even discuss TunSafe.

You need to follow the thread.

Previous HN discussion on TunSafe from earlier this week: https://news.ycombinator.com/item?id=16515637

I don't know how reasonable it is, but the attitude of the WireGuard maintainer in that thread really puts me off using it. Call it the de Raadt effect.

Did it put you off using openssh/openvpn/libressl/etc? Is there the Torvalds effect? Let maintainers express their discontent in the form they prefer.

I see how @zx2c4 might be concerned about possible reputation risks due to the release of this closed-source implementation at the earliest WireGuard stage. Given that the author of TunSafe is not a security expert. Especially if (suddenly) TunSafe turns out to have security flaws, right before the WireGuard team releases an official open-sourced implementation. However, WG is an open protocol, and @ludde has the right to develop and sell whatever he wants on its basis.

I'd say the author comes across as immature, which is kind of a bad look if you are making security software.

How, specifically? Are they immature for suggesting against using a closed-source implementation of the WireGuard protocol? Is your concern their tone about said implementation?

It didn't stop me using them, but it certainly is off-putting. It's not a black and white issue though. The value I get from Linux easily outweighs any issues from Linus being a bit of a knob. I'm also unlikely to have to deal with Linus as a user. WireGuard, on the other hand, is a small project where the maintainer jumps in to discussions on HN. If that's how he behaves here, I'd rather not have to deal with that if I have a support question.

Might be more appropriate to compare with "ssh" and a Tatu Ylönen-effect in the case of ssh. Although openssh certainly became a significant fork.

Same here. I was planning on using WG for personal infra and was actively routing for it in a corp environment, but his attitude has put me off. I'm sticking with OpenVPN for the time being.

I use viscosity as my openvpn client on macs. I love Viscosity and was planning on asking them to support WG. Not anymore though... The author seems to be stuck in a past where closed source vs open source was a binary decision. We've gone past that point in history.

It's one thing to say "I can't or won't vet a closed source client, so I can't officially support it" and another to actively advise against it.

On the other had TunSafe could hire a well-known third party agency to go through the source and vet the agency for security holes. That would add back and credibility taken away by the way the author responded. Since the project is open-source, if I had the resources, I might go as far as pay the same agency to vet both close-source client and the open source server implementation... But we're not talking about Cisco/Juniper/Major-Vendor here, so I don't see that happening.

@ptacek (or anyone else working on this space) how much would it cost to vet wireguard for security holes? Is there a standard way of charging (e.g. per lines of code) or depends on multiple variables? ps. Asking ptacek because of his prev comments [1].

[1]: https://news.ycombinator.com/item?id=14598639

> @ptacek (or anyone else working on this space) how much would it cost to vet wireguard for security holes?

You may be interested in @ptacek's response on this matter a while back[1].

[1] https://news.ycombinator.com/item?id=16327350

Off-topic from that thread:

"(...) we're hosting the dude who wrote the Wireguard go implementation this summer (hey Mathias)"

Which pointed me at:

https://www.wireguard.com/xplatform/

I didn't realize there were some real efforts underway for cross platform support - that makes wg much more interesting (for my use-cases). Good to know! (I can live with higher performance linux-linux than linux-windows, mac-linux, linux-bsd etc; but forcing the need for a Linux "vpn router" as a vm or physical box is a tough sell. Not to mention a need for a real client for smart phones, though I suppose it should be possible to run wg on a rooted/custom rom Android phone, it'd be nice to have regular Android and ios clients).

> The author seems to be stuck in a past where closed source vs open source was a binary decision. We've gone past that point in history.

I'm not sure what you mean by this. We are at a point in history where 100% open source is more important than ever before.

I have always found it odd that people seem to feel the need to personally like the creator of something.

There’s a difference between liking someone (which doesn’t really matter) and trusting their judgement (which is what I think folks mean here). I feel it’s somewhat important for the later to be true, especially with security related software.

Is there evidence that this generally leads to more security vulnerabilities? Is there evidence that specifically in WG, Jason's (technical) judgement has been flawed?

(I think the answer is "no" in both cases. Disclaimer: my company also donated to WG development, specifically to get cross-platform support :))

I could make arguments for both sides on both your questions. I wasn’t voicing an opinion there however as I’ve not seen enough to have one yet.

You are not alone, see the following exchange on LKML, where Donenfeld immediately "disciplines" another subscriber for asking some minor question that was not 100% on topic:

https://lkml.org/lkml/2017/12/7/1745

Follow-up by David Miller:

https://lkml.org/lkml/2017/12/8/533

That said, I like the idea of WG like I liked the idea of systemd.. but Donenfeld just seems to be another Poettering in the making.

To be fair, his own reply to that was reasonable: https://lkml.org/lkml/2017/12/8/714

I feel the opposite way.

Subscribed to the Wireguard mailing list for a while and the author seems very friendly, even to help requests that are really .. stretching what a mailing list should be for.

Yes, this reply was rather harsh, but if there's someone who jumps on a somewhat popular project and implements (competing, it seems cross platform clients are 'coming soon') commercial/closed source clients than I do understand some .. frustration.

On top of that: Both the author of TunSafe and Wireguard seems to agree that - at least on Windows - TunSafe requires a rather scary tun driver?

(I am not a security expert..)

Also the official not-ready-yet WireGuard cross platform Go/Rust clients require this "scary" driver.

If you've created a new open protocol I'd imagine most people would welcome new implementations, especially on platforms that you don't currently support.

Maybe. Probably. And I think the guy does?

He doesn't seem to feel good about a closed source implementation completely disconnected from the project, for a protocol that is as of now unreleased, only releases snapshots with large warnings to not yet depend on it.

The attitude makes sense to me, from a developer's point of view (Will TunSafe follow Wireguard changes closely? How sound is it, compared to the project's own codebase?) and a project's/personal point of view: Someone invests a lot of time into Wireguard and before it's "ready" someone else builds closed source clients with a fancy website for the two biggest operating systems. YMMV.

Is it possible with wireguard to provide public IPv6 address for clients? My server has /64 subnet assigned, and clients have only IPv4, but I'd like to provide white IPv6 address for clients.

yes, I've done this

Is there by any chance a speed comparison against IPSec (IKEv2) i.e. strongSwan with AES-NI?

I haven’t used OpenVPN in many years, so such a comparison would be much more interesting.

From experience I can tell you that IPSec is much faster than OpenVPN.

I have no issues getting Gbit over IPSec (Strongswan), but with OpenVPN I always maxed out around ~400Mbit.

EDIT: Looks like I misunderstood your comment and it seems like you want a comparison to Wireguard... oops

Yeah that’s my experience as well. That’s why I wanted a comparison. My router at home easily handles gigabit over IPSec even though the CPU is at least 8 years old.

It's extremely fast, the benchmarks I've seen show that it's even faster than the IPSec config you describe.

> the benchmarks I've seen

I think GP was asking for links to that, able to share?

There are some benchmarks here https://www.wireguard.com/performance/

Preliminary benchmarks are available on the website.

https://www.wireguard.com/performance/

EDIT: Note these are obviously for the reference implementation, not TunSafe.

Interesting, haven’t run IPSec under Linux, is this expected performance?

Seems rather low compared to what I’ve experienced under FreeBSD. An i7 Ivy Bride & Broadwell and should be aleast comparable to my almost decade old Nehalem-EP Xeon, shouldn’t it?

Well, there are a few mitigating factors.

First, these are the mobile variants of the CPUs, which are usually slower than their desktop counterparts out of the box, and clock lower more often due to thermal management kicking in a lot, too.

Secondly, a gigabit network card was used, which sets a low ceiling for the benchmark.

Thirdly, these were results averaged over 30 minutes (which again may cause heat issues in some laptops), not burst performance; I doubt OpenVPN would even register on a graph of burst performance of, say, 3 seconds.

Lastly, from what I hear, the Linux IPsec stack is a lot more complicated than is typical. Granted, they're all complicated, but still ...

Reply on news.ycombinator.com