8 ms·

This seems solvable. They talk about that here: https://tailscale.com/kb/1099/device-authorization/ https://tailscale.com/kb/1099/device-authorization/ But it

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.