Hacker News

Do you use tailscale ssh but either dont have sudo, or don't permit login as root?

If all your tailscale-ssh ACLs allow you into an account with sudo, or allow you into root, theres no impact (you cant do anything with these vulns you couldnt do a month ago). Thats the nuance I'm trying to get across (admittedly my english is bad).

Engineers use vanilla SSH for SSH, Tailscale SSH is more focused on enterprise stuff where you can have an audit trail of all commands executed and enforce ACLs.

Tailscale SSH is different than doing SSH with Tailscale

I’ve used tailscale in quite a few jobs now and not one have we used tailscale ssh. Call us old school or whatever but at my current place of employment we provision ssh keys on a box with ansible and just use regular old ssh over the tailnet, not tailscale ssh

I use tailnet as a vpn and ssh into my server via the tailnet, but I dont use tailscale ssh the product. I think most people fall into this bucket.

Of course it should be taken seriously, but this topic is also piggy backing off of 7 days straight of non stop viral engagement farming on X after php2shell, where people we're farming likes by just posting stuff like

"YoU ThInK PhP2ShELl iS BaD JuST WaIt unTiL TaIlScAlE get HaCkED, ThIS JuSt ThE BeGiNNiNG oF a CybeR ReCKoNiNG"

To farm FUD from normies. Which of course led researchers who were working on tailscale vulns to take advantage of that algorithmic attention as well and talk about their research.

Like Im pretty sure we knew about this vuln for 3 days now, or atleast that it was responsibly disclosed (and not being used in the wild).

The attention this is getting is definately the product of some cringe viral snowball effect of the also rather benign p2pshell vuln.

It feels like there's a ton of AI influencer astroturfing going on, because its wildly easy to get engagement when you add the words "agent/ai" with "vulnerbility" and [insert popular service].

The vast majority of tailnets are just hobbyists on the generous free tier and probably don't use tailscale ssh, but rather ssh over a tailnet. Usually it's either just one person or a family sharing access to the tailnet. But for corporate accounts where ACLs are used for SSH yeah this is big.

Privilege escalation is now nothing to worry about?

Flagged by who? The Internet Police? This comment is absurd.

Naive. There's not much that prevents you from running ssh over https. Not even traffic patterns will give you up in the age of ubiquitous websockets and/or http2 streams.

My Tailscale RCE[1] in 2022 involved forcing a device onto an attacker-controlled control plane, at which point your device is no longer "yours", and the fact that Taildrop is implemented in your client binary can be exploited. Chaining the bug to RCE would not have been possible against an ideal Tailscale with only the core feature set.

[1]: https://web.archive.org/web/20221222120703/https://emily.id....

See my comments in this thread.

I've been toying around with nebula, self host your lighthouse on a cheap VPS (which even if it gets hacked, the most it can do is lie about traffic, not lie about node certs). Basically you're just paying for the punchthrough (you may even be able to do some duckdns shenanigans?) The main issue is that updating nodes is a pain in the butt, which is the main advantage of tailscale IMO - centralized control plane. Keeps it simple.

I was trying to do some kind of insane workflow where you as the operator have a privileged hardware yubikey that admins the nodes when you plug it in, and the point is the nodes would self-propogate the changes outwards. I immidiately ran into classic issues with distributed security in distributed systems (even with only one central operator trying to admin everything). Tailscale is also a bit more secure in its oauth layer - with this architecture, you need to set proper time limits for expiring so one node compromise doesn't get access to the whole fleet. Couldn't really come up with better ideas than forcing the operator to reuse some kind of hardware key (the idea trying to be avoiding maintaining a cloud control plane as much as possible)

Fun foray but creating such a system requires a lot of expertise that I unfortunately lack

https://github.com/netbirdio/netbird

Bit more than the basics, but not as much as tailscale.

You can run Tailscale in this mode just fine, or use Tailcat if you want.

You could just use IPsec. It’s been probably 20 years but look into SWAN. It’s just a vpn in the vpn sense.

No.

{tail,head}scale is the best there is for wireguard at more than 3 nodes.

Tailnet owner may not trust all their devices to the same extent. Here is a concrete example.

I install tailscale on my cloud vps which I use for downloading torrents. I want my laptop to talk to this node, but I don't want this vm talk to my laptop, which is the whole purpose of ACLs. My ACL is deny by default, so that is great and easy to set. But now this node can still send arbitrary files to my laptop. If I don't remember to tag it, I'm vulnerable. If I do, there is still a window that this node can send me files until I tag it (I can't install tailscale to a tag).

Sending a file otherwise normally requires an app listening to a port, so taildrop permissions should be same as network permissions set by ACL.

BTW, last year or so tailscale advertised a position for someone to manage complexity of tailscale. Founder was talking about this issue. They seem to be aware of the problem.

I think it contains a lot of information. Simple definitions always need a human touch

As I understand it, that use case isn't impacted by these vulnerabilities since it's not using Tailscale SSH, just OpenSSH over Tailscale.

Always is your responsibility even with tailscale. Now it is his responsibility without tailscale.

Attack surface almost entirely goes away if you just require a good port knock first! I do that with my protection SSH servers and it works just fine. Also prevents anyone from knowing there even is an SSH server there. Or any server if it doesn't respond to pings either, and only uses reverse tunnels to accept public connections

With AI, the complexity doesn't really matter anymore. Codex or Claude can easily configure complex site-to-site setups and peer configurations on mobile devices. I did this by hand before and it was hard and difficult to get right. Now I just tell AI and it does so perfectly, checks and verifies things. AI made life so easy.

Don’t think that refutes their point.

I prefer it too and I like that it's 100% open source. Server, client, everything. Pangolin also looks interesting if you don't need a full vpn. And if you go that way, Authentik with its embedded proxy is also worth considering.

+1

I am a relatively old school engineer. When building a bricks and mortar business recently I kept hearing about tailscale for remote access. Looked and saw it was just a wrapper over wireguard. I immediately went aha, there's a solid underlying project without the risk of something over the top trying to make life easier for people unwilling or unable to manage their own systems. Went with a direct wireguard on opnsense approach.

Bamn, proved right today.

Wireguard is perfectly elegant and maintainable as it is for me, and a wonderful improvement on traditional site to site VPNs.

This exactly. All the extra stuff Tailscale provides buys convenience, but increases complexity, the attack surface of the stack, and adds commercial components to an otherwise open protocol. Call me old fashioned but I will keep managing keys manually.

Thanks for linking that. The debate about these issues will rage on, but I do wonder whether giving Tailscale two hours of notice before public release was the right call? The arguments from the post are that "rapid awareness of these flaws will expediate remediation" and that they were "discovered with low effort". Does the author mean that simply pointing Claude at Tailscale identified (a non-trivial subset) of these vulnerabilities, and did the author not feel that Tailscale had a track record of responding to vulnerabilities, via a coordinated disclosure, in a timely manner? I would personally have liked to see a bit more of a justification of the almost-immediate publication against the potential risks to users, vs. e.g. waiting a day or two.

10,000 words of claudish, it's not worth reading.

Given what just happened with PHP a few days so, it's not surprising to me that they're holding their cards close to their chest. People will already be doing their damnedest to reverse engineer the exploit with this meager info.

Have you seen the slopreport for the vulnerability?

I fully understand being carefully worded when you need serious brain power just to figure out every claim in the logorrhea

> Obviously tailscale has some great devs, security is complex.

Quick reminder that in recent months Tailscale has had issues with age-old classic vulnerabilities such as input validation.

The problem with Tailscale is twofold.

First their attack surface is too big. They continuously shoehorn new features into the product.

Second they don't appear to do regular deep-dive code audits and instead they appear to rely mostly on the goodwill of third-parties to poke at select areas of their code as and when those third-parties feel like it. Hence simple vulnerabilities such as input validation keep on popping up.

Fancy SOC2 certificates are not the same thing. That's just dogfood for the corporate auditors.

At $work we are busy working on removing Tailscale. The bells and whistles of Tailscale sure are attractive candy, but we simply can't overlook the security risk of what has become a bloated product.

we'd love to hear about it at security@tailscale.com, we're happy to work from & with and credit early ideas as well.

I've never used it once. don't even see the point. normal ssh works fine over Tailscale.

What is the advantage? Why would I want to swap the well tested auth in ssh for auth managed by tailscale?

It’s also not even available on some platforms afaik