Hacker News Reader

Comment by mike_d | Hacker News Reader

How was the decision made to roll this functionality out before announcing it to customers (we found it during a previous security audit)?

While it might seem logical in your mind to bolt on extra features and add value, your customers evaluate risk based on functionality of the software they are approving. Customer buys a VPN solution, magically gets remote access that bypasses firewalls. Can we trust Tailscale to not roll out a remote file backup feature and start silently exfiltrating data (as an extreme example)?

View on HN

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?

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.

Ohhh, this explains why my corporation placed a total firewall block on the Tailscale website.

This is a postmortem-worthy incident on Tailscale's part.

If you're not already using Tailscale, with your security or IT teams controlling it, it would be malpractice to allow it on a controlled network. No competent security team allows people to introduce their own VPNs.

The way it works in enterprise that is principal engineers like me are generally given some freedom to explore new technologies responsibly. In my mind, that includes visiting the Tailscale website (which started being blocked by our IT yesterday) to gather information about whether this would be a good alternative technology for our research teams.

Now what I have to do is file a bunch of tickets and take a bunch of meetings to get a block removed from the overall site. Really, what I was trying to do is provide nformation to the Tailscale developers that enterprise already considers their website/product scary enough to do a whole block, and if they want to expand into enterprise, they may want to understand the reasons for that.

> Now what I have to do is file a bunch of tickets and take a bunch of meetings to get a block removed from the overall site. Really, what I was trying to do is provide nformation to the Tailscale developers that enterprise already considers their website/product scary enough to do a whole block, and if they want to expand into enterprise, they may want to understand the reasons for that.

Not all large enterprises are this disfunctional. I'm sure Tailscale are doing just fine.

Blocking the tailscale website has nothing to do with blocking the VPN. I know you're passionate about them, but I think you got baited here...

Who’s talking about blocking a website?

dekhn, three comment levels above yours.

You're right. I guess my brain wouldn't let me process something as dumb as a corporate security control based on blocking a website to keep people from installing a binary.

Anyways, I'm just here to say, corporate security teams are definitely not OK with you doing a rogue Tailscale install, and that's as it should be.

Anyways, I'm just here to say, corporate security teams are definitely not OK with you doing a rogue Tailscale install, and that's as it should be.

You might be shocked at how often I get "can you deploy a tarsnap server on port 443? My company's security team won't let me connect to your server on port 9279" requested.

I mean, it's trivial to bounce the TCP connection... but I'm not going to help subvert security policies.

I work for a Fortune 100 company and this is precisely what our corporate overlords do with non-approved VPN software. There are device management tools on every machine in the corporation to detect and block the software, but that isn't turned on. Just blocking the website. ¯\_(ツ)_/¯

Speaking of which, how would they detect it?

Any good network security monitoring system should allow it to be fingerprinted in some manner, and if deep packet inspection is in use then it should be blocked outright.

It's likely just because it's a VPN not under control of the corporation. Corporations have this magical wand which they swing to make it hard for people to do their work :)

Reply on news.ycombinator.com