5 ms·

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 featu

by aborsy 4y ago

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.

sneak 4y ago
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.
- crawshaw 4y ago
  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.
  - sureglymop 4y ago
    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/ https://tailscale.com/blog/opensource/
    - bradfitz 4y ago
      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.
      - makeworld 4y ago
        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/ https://tailscale.com/blog/opensource/
        atonse 4y ago
        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.
        mbreese 4y ago
        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.
        fomine3 4y ago
        Or their own server is too big for small use so not welcomed by selfhoster, like Bitwarten/Vaultwarden case.
        bradfitz 4y ago
        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.
  - unshavedyak 4y ago
    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)_?
- jyrkesh 4y ago
  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...
  - zikduruqe 4y ago
    Or if you are a small org, use GitHub Organizations for up to 25 people. https://tailscale.com/blog/community-github-pricing/ 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.
    - jyrkesh 4y ago
      > 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.
fragmede 4y ago
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.
- akerl_ 4y ago
  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).
  - dvzk 4y ago
    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.
    - nine_k 4y ago
      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.
      - dvzk 4y ago
        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.
lilyball 4y ago
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 https://github.com/juanfont/headscale

by aborsy 4y ago

sneak 4y ago

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.

crawshaw 4y ago
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.
- sureglymop 4y ago
  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/ https://tailscale.com/blog/opensource/
  - bradfitz 4y ago
    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.
    - makeworld 4y ago
      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/ https://tailscale.com/blog/opensource/
      - atonse 4y ago
        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.
        mbreese 4y ago
        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.
        fomine3 4y ago
        Or their own server is too big for small use so not welcomed by selfhoster, like Bitwarten/Vaultwarden case.
        bradfitz 4y ago
        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.
- unshavedyak 4y ago
  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)_?
jyrkesh 4y ago
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...
- zikduruqe 4y ago
  Or if you are a small org, use GitHub Organizations for up to 25 people. https://tailscale.com/blog/community-github-pricing/ 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.
  - jyrkesh 4y ago
    > 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.

fragmede 4y ago

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.

akerl_ 4y ago
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).
- dvzk 4y ago
  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.
  - nine_k 4y ago
    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.
    - dvzk 4y ago
      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.

lilyball 4y ago

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 https://github.com/juanfont/headscale