Hacker News Reader

Comment by bradfitz | Hacker News Reader

There are two things have have to be enabled to turn it on:

(1) a target server needs to run "tailscale up --ssh" to enable the SSH server

(2) your Tailscale ACLs have to permit it. Our default, if you've never set your ACLs (as is usually the case for personal users), is that you're allowed to SSH to your own untagged devices only.

For an org that's already using ACLs, you won't have any SSH rules defined and thus nobody in your org can enable the SSH server. (Or rather, they can enable it but nobody can connect to it.)

If your concern an org that's using the default "all packets are allowed" ACLs?

View on HN

That's one part of it.

I can't speak for mike_d specifically, but there is a concern with having (potentially significant) modifications made to the codebase that aren't surfaced in the release notes. I imagine closed-source projects do this on a regular basis whether customers know (or care) or not.

The expectations for opensource projects are different though, particularly when it comes to system-level or near system-level components. So not being able to access the functionality is a great default but it doesn't address side effects of the changes or the desire to know about changes being made in our environments.

I’d think that the literal ability to audit the source code would satiate one's desire to know about the changes being made in their environment.

Of course it doesn't. Only the actual auditing of the code could do that. Nobody in the world wants to audit code they are relying on every update to make sure that the developers have not added potential new security concerns that they would otherwise not be aware of.

Concern more around what looks like an ssh backdoor showing up unannounced. How would they know the subtleties of what it takes to enable it when it wasn’t announced yet?

Try to look at it without your inside knowledge of how it works. Think about a customer discovering this with no documentation.

Until you decide to ship a completely on-prem Tailscale server, ACLs mean nothing. They can be modified by the same rogue employee that added an SSH server that bypasses local firewalls to our environment without telling anyone.

If you're unwilling to trust Tailscale and their processes, you can't run Tailscale right now. That's obvious. It's part of the premise. The idea that ACLs "mean nothing" is risibly reductive; the ACLs protect our team members from each other and mistakes they might make with their environments.

(We don't use Tailscale SSH, and are unlikely ever to; we have a separate source of authentication truth for SSH, and a separate certificate-based access control system.)

They built a footgun into a toaster, and victim blame when people complain that they thought it was just supposed to make toast. Users should not be put into a situation where they need to configure ACLs in anticipation of undocumented features.

My hope was that with a little public prodding they would do better in the future. It is a product I want to like, maybe not for what you or I do, but lots of folks out there are slinging cat pictures where it will be a net benefit.

"Victim blame". They announced an opt-in feature.

Ah, I see the part you are missing. It was rolled out before it was announced or documented. We found it during a pentest.

Reply on news.ycombinator.com