3 ms·

"allowing them access into my personal network" In what form? The private keys never leave the nodes, hence there shouldn't by any access per se (see https://t

"allowing them access into my personal network" In what form? The private keys never leave the nodes, hence there shouldn't by any access per se (see https://tailscale.com/security/ https://tailscale.com/security/). Of course TS has insights into your networks, i.e. what servers it is installed on, what you connect to - so metadata.

stavros 4y ago
They can add a node and connect to whatever other node they want.
- ec109685 4y ago
  This seems solvable. They talk about that here: https://tailscale.com/kb/1099/device-authorization/ https://tailscale.com/kb/1099/device-authorization/ But it still seems like they could flip that feature off if they got compromised. To remedy that, feels like they could support a preshared secret that they don't control / see being shared as a first step: https://tailscale.com/kb/1099/device-authorization/#generate-an-auth-key-which-is-pre-authorized https://tailscale.com/kb/1099/device-authorization/#generate...
  - stavros 4y ago
    Yeah, they control this setting so they can just disable it, or override it. Since Headscale exists, though, this problem is solved quite neatly.
  - yencabulator 4y ago
    You can't generate a secret with a webapp they control without them controlling the secret too.
    - stavros 4y ago
      I assume the notion was that the nodes will all know the secret but the control server won't.
      - ec109685 4y ago
        Exactly. Pre-shared secret out of band.
  - yencabulator 4y ago
    I think the Tailscale part that actually knows what auth keys look like is proprietary, but at least for Headscale they seem to be just unguessable database row identifiers: https://github.com/juanfont/headscale/blob/ade4e23e149e7846ba00643903fa40cc12216618/preauth_keys.go#L37 https://github.com/juanfont/headscale/blob/ade4e23e149e7846b... Nothing in the Tailscale design has ever pointed to features that would guard your infrastructure from them.
- moontear 4y ago
  Haven't thought about that and this should certainly be addressed - especially if I'd use Tailscale for business.

stavros 4y ago

They can add a node and connect to whatever other node they want.

ec109685 4y ago
This seems solvable. They talk about that here: https://tailscale.com/kb/1099/device-authorization/ https://tailscale.com/kb/1099/device-authorization/ But it still seems like they could flip that feature off if they got compromised. To remedy that, feels like they could support a preshared secret that they don't control / see being shared as a first step: https://tailscale.com/kb/1099/device-authorization/#generate-an-auth-key-which-is-pre-authorized https://tailscale.com/kb/1099/device-authorization/#generate...
- stavros 4y ago
  Yeah, they control this setting so they can just disable it, or override it. Since Headscale exists, though, this problem is solved quite neatly.
- yencabulator 4y ago
  You can't generate a secret with a webapp they control without them controlling the secret too.
  - stavros 4y ago
    I assume the notion was that the nodes will all know the secret but the control server won't.
    - ec109685 4y ago
      Exactly. Pre-shared secret out of band.
- yencabulator 4y ago
  I think the Tailscale part that actually knows what auth keys look like is proprietary, but at least for Headscale they seem to be just unguessable database row identifiers: https://github.com/juanfont/headscale/blob/ade4e23e149e7846ba00643903fa40cc12216618/preauth_keys.go#L37 https://github.com/juanfont/headscale/blob/ade4e23e149e7846b... Nothing in the Tailscale design has ever pointed to features that would guard your infrastructure from them.
moontear 4y ago
Haven't thought about that and this should certainly be addressed - especially if I'd use Tailscale for business.