Hacker News Reader

Comment by freedinosaur | Hacker News Reader

> In theory, there is no path for a malicious Tailscale control plane to remotely execute code on your machine, unless you happen to run network services that are designed to allow it, like an SSH server with Tailscale-backed authentication.

Now I feel less crazy for not using Tailscale SSH for similar reasons.

I'd like to see a security evaluation of Tailscale, on a per feature basis.

I'd like to see tailscaled run with far fewer privileges.

Is there a Tailscale alternative that just does Wireguard + NAT traversal and doesn't try to do key management?

View on HN

Yep. Same boat. Absolutely zero interest in granting them ssh authZ; transport wrapping is all I want to outsource. Just deliver my bits and I pay you, tyvm. My suspicions have been proven correct here.

Unfortunately reading about this remote RCE vector has me wondering whether I can use the product at all without all this bloat (taildrop, ssh, etc) affecting me. Going to have my team look at zerotier this week, I’ve heard a few ok things.

Top result on HN: https://news.ycombinator.com/item?id=28590625

"Zerotier: multiple vulnerabilities lead to private network access."

Saw that when it came out, yikes, but here it makes my point for me.

The zerotier software failed - as such you could (in the simplest terms) bypass the transport “firewall”. At no point could you execute code on my machines. At no point could you spoof any authorization layers outside of what’s required to reach my ports. So when the model catastrophically failed here, attackers still cannot login to my machine. Other attacks might make this possible (e.g. code exec in the agent), but were not found - I suspect due to the lack of attack surface.

All software can have serious bugs, which is why you do defense in depth. Never depend on just one thing for your entire security perimeter.

Outside narrow very well defined cases where proofs of security are possible, it might be impossible create perfectly secure computing systems due to the insolubility of the halting problem and the sheer size of the combinatorial space.

If you watch the CVE announcements it's a continuous stream of serious bugs in all kinds of major software applications including OSes, web browsers, networking hardware, VPNs, cryptographic libraries, and so on. Microsoft, Apple, Cisco, etc. have serious vulnerabilities fairly often.

Wireguard never had, and probably will not have, a serious vulnerability (one allowing bypassing a tunnel). The attack surface is small, and you can carefully review the code, even formally verify it. The devices could all tunnel out to a nearby VM in the cloud.

This vulnerability is very critical, and discovered by an undergrad (not a security team): Code execution in local machine, taking over tailscaled, hijacking the coordination server, adding nodes, SSHing into machines, SMB shares, etc. The users are owned if attacked, and this was supposed to be a security-focused product.

Part of the problem is the feature bloat, that Wireguard deliberately avoided. Like, I want a mesh VPN, not an alternative to OpenSSH or Dropbox as well. The integrations add code, and it’s hard to secure a larger code base.

The response from Tailscale has been excellent though. Hopefully they will take measures to prevent such issues. This is a VPN after all!

> Wireguard never had, and probably will not have, a serious vulnerability (one allowing bypassing a tunnel).

True, but even the bare minimum WireGuard VPN still has a lot of stuff other than WireGuard. There's going to be a configuration protocol, software to create a tunnel device on the system, a management protocol, software updates, a UI, identity management or some kind of login/auth system, etc.

No one is asking for “perfect security”. We all agree with you, that is impossible. What many security professionals want from this product is a stable network transport tunnel with well-defined attack surface. We understand defense in depth, which is why we disable ssh authZ in tailscale, for example.

Now imagine you are an enterprise user of tailscale, you diligently elected not to trust it with login to your boxes, but you still got pwned because of “taildrop”, a feature no one on your team uses, wants, or knew was enabled.

Software vulnerabilities happen at a rate that highly correlates with size of attack surface. The attack surface here is pretty clearly too high (bad “defense in depth” as you say), and I hope they provide mechanisms in the future for disabling all this bloat, otherwise offerings like zerotier will eat their lunch.

> I'd like to see tailscaled run with far fewer privileges.

Yeah - I have a dislike for services running as root when it's not necessary, and then getting users to escalate to root to interact with them routinely.

One thing I was thinking about was trying to identify the Linux capabilities which let tailscaled run, and then look at if it's feasible to adjust the default systemd unit to run it as a non root user. Closely followed by then trying to harden up the service with as many of the recommendations as possible in "systemd-analyze security".

Despite there being a pretty good range of restrictions available, it seems to be pretty rare that service definitions actually come locked down... Might be something for the tailscale team to look at in future?

Software shipped by the distro maintainers I find is often properly locked down with systemd features, but third party stuff is always hit and miss. Definitely agree Tailscale should be shipping with the bare minimum privileges required.

I use a cheap public VPS and Wireguard and it works over my ISP connection at home. My servers run here at home but are only publicly visible at my VPS public ISP address. Is that the same as what you're asking for with 'NAT traversal'?

If so, the config is straightforward for techies, just Wireguard config, it routes into my home server and I use Apache Reverse Proxy to route to the backend services.

https://github.com/jwhited/wgsd does NAT traversal with Wireguard, but you need to operate a CoreDNS server to do it.

More info on how it works: https://www.jordanwhited.com/posts/wireguard-endpoint-discov...

Yeah the whole "run local http server as control panel" is iffy for non security centric stuff, let alone VPN software.

I guess it is because it's easy ? But now even windows can make unix sockets, that seems like reasonably easy and secure solution for "talk with some daemon portably"

> Is there a Tailscale alternative that just does Wireguard + NAT traversal and doesn't try to do key management?

I really wish there was a NAT traversal protocol or library that wasn't overly complex and focused on the 90% cases. It would help not just tailscale's but anyone building p2p tech.

I wonder if IPv6 will ever be the “path of least resistance” vs. NAT punching.

You usually still have to punch with IPv6 as there is usually a stateful firewall in the way. You just get 100% success vs the 80-90% you get with V4 (and getting worse as CGN gets more common).

This is correct. It's very annoying for any p2p like application, because the punching is a coordinated and time sensitive dance that just circumvents particular firewall bs. The firewall approach comes from this heavily flawed idea of the client initiated model of communication, extrapolated to client=consumers and server=service providers. It's just awful that the majority of the nodes on the internet aren't even reachable by default.

Anyway, it would be much better to leave the socket APIs to handle this, possibly with OS safeguards and privileges. Writing p2p applications is analogous to being constantly protected "for your own good" by a guardian. /rant

It's used like that because for a long time that approach worked. Users are terrible at securing their own machines and will click yes on anything just to get a thing they want and so putting stateful firewall allowing only outgoing connections was very effective measure.

Much less relevant when now even windows comes with half decent, reasonable default firewall out of the box. Then again "user clicking allow button till it works" is still a problem.

> It's just awful that the majority of the nodes on the internet aren't even reachable by default.

Who'd pay for the routing? :)

I believe libp2p has some NAT traversal stuff: https://docs.libp2p.io/concepts/nat/

https://github.com/hyprspace/hyprspace is built on top of that. It's remarkably simple: libp2p's DHT + libp2p's NAT punching + TUN device.

I don't think it offers authn/authz, but that's fine: neither does my ISP. I just want SSH reachability.

Twingate comes close - not wireguard (uses QUIC) but does NAT traversal and doesn’t try to interfere with intercepting/manipulating network traffic.

Focus is more on device identity/posture, DNS + remote access rather than straight VPN like Tailscale & co

I have a task to investigate https://www.firezone.dev

Nebula might fit, but it’s not wireguard specifically.

Reply on news.ycombinator.com