Hacker News Reader

Comment by aborsy | Hacker News Reader

I am one of those users who have asked, but how can I trust that the Tailscale coordination server will not inject hidden public keys to my network.

This feature is a very good step forward in security. I will take a look and if the implementation is sound, I am going to use Tailscale (namely if the Tailscale is compromised, I will not be automatically compromised, unless I manually accept external public keys, or install a bad update).

The problem with malicious updates can be addressed by providing as easy way to check the code signature. With a standalone infrequently updated app such as an AppImage app, this can be easily done by verifying the GPG signature upon download.

View on HN

If you don't want to trust the Tailscale coordination server, and decide that tailnet lock is not for you, have you taken a look at Headscale? https://github.com/juanfont/headscale

How can I trust that I can log in and administer my network when Google kills my Google Account login or Microsoft kills my GitHub Account?

Big tech surveillance orgs being the SSO is an SPoF for the administration of the network. For something as critical as L3, I can't accept that.

I just use Nebula instead. It doesn't have a spiffy web interface or ssh auth chrome bolted on, but it works great for my purposes and it doesn't involve Google or Microsoft at any point.

Tailscalar here.

IdP trust is on the list. There are some "easy" things we can do that help on the surface but make life harder for users. And there are some not-so-easy things we are researching. I hope to have answers in 2023.

I recently read this blog [0] about how tailscale was thinking of open sourcing a small coordination server but headscale had already been created so that effort was put on hold.

Is tailscale at this point in any way involved in headscale or contributing to it or are there plans to fork it to keep it maintained?

Asking out of curiosity.

[0]: https://tailscale.com/blog/opensource/

We hired one of the Headscale developers and let him work on it (as part of his job, not just moonlighting) and we help out when there are issues and give them a heads-up when protocol changes/etc are coming.

This is such an outstanding response to the existence of Headscale that I struggle to understand it. Why not just open source Tailscale's control server? Don't get me wrong though, what you guys are doing now is great.

Edit: some explanation here: https://tailscale.com/blog/opensource/

My guess would have to be that their version is probably deeply integrated with the rest of the product and infra that it doesn’t make sense.

Plus there’s the added benefit to their paying customers to know that we have an out if needed. It reduces friction in starting to use the product.

There’s another added benefit that they get two different implementations of the same protocol. When you have multiple implementations, you effectively have a double check on the protocol design. This should make the project as a whole significantly better engineered.

It’s quite clever from Tailscale.

Or their own server is too big for small use so not welcomed by selfhoster, like Bitwarten/Vaultwarden case.

Yeah, that's probably very true. Our main coordination server should probably get easier to run (for our on-prem customers and our various country-specific instances we run) but Headscale is far ahead of Tailscale's on just being easy to run.

That's great news! Makes me confident to actually try out headscale+ tailscale! Thank you.

re: IdP, assuming that means signing up without Microsoft/Google (which really bother me too), would it be possible to migrate a Github account to .. whatever you all implement _(email signup/etc)_?

I totally empathize. I waffled on Tailscale for a long time, and was convinced I'd roll my own for everything.

But goddamn if that spiffy web interface is not just the bees knees. I relented and put in a Google account that I don't use very often for identity--no idea if that makes it more or less like to be arbitrarily banned by Google--and accepted the fact that access to Tailscale wasn't so critical for me that I needed to be worried about it.

But in production, I totally get it. But I'd probably still just pay for Tailscale's SAML and use Okta or something...

Or if you are a small org, use GitHub Organizations for up to 25 people.

https://tailscale.com/blog/community-github-pricing/

I have been using Tailscale since the beginning personally, and have been trying to sell it internally at work, and since we have a GitHub Community I have integrated various Tailscale machines into some of our playground environments for others to test out.

> and have been trying to sell it internally at work

You are like, the dream of all B2B SaaS startups.

But also, Tailscale is great, fight the good fight.

One option is don't. Run tailscaled inside a container with host network access, that way you can connect to the host, but it doesn't have the ability (unless it escapes the container) to write (ssh) keys.

I think y’all are talking about different things; the parent comment seems to be talking about injecting additional keys into the tailnet (basically, letting other devices communicate inside your Wireguard VPN).

That's actually the point of this feature. Before, the key distribution server could add unauthenticated Wireguard nodes to your peer list. Now, the tailnet administrator can tell Tailscale nodes to reject new peer public keys unless the key is cryptographically signed by a trusted node. If you don't trust the implementation, wait until it's audited, I guess.

I wonder if a third-party solution for the signature key distribution is feasible; I suppose it should be, because it's appears to be just a file.

This way, if you don't trust Tailscale to distribute these lock-controlling keys, you could run a different mechanism of your choosing that would effectively control what nodes are automatically admitted.

Based on the article, the private keys for peer enrollment signing are generated locally on each Tailscale client and aren't distributed at all. I don't see why you couldn't write a custom client that approves or denies new peers based on your own criteria. Some of the internal Tailscale API may first need to be officially documented.

Reply on news.ycombinator.com