6 ms·

I'm not entirely convinced I want a feature that adds even more exposure to the sort of goofy login flow Tailscale has.

tptacek 4y ago
It's helpful for people to know, from context later in the thread, that one of the core concerns behind this comment is the idea of using SSO at all, and thus giving "the keys to the kingdom" to Google. Of course, it's also worth knowing that SSO is basically a universal best-practice for security teams, and while it's not de jure required by SOC2, it's almost de facto required. For once, I think the best-practices and compliance people have this one right: you are extraordinarily unlikely to get burnt for trusting Google in this instance, and the security track record of ad-hoc authentication is worse than abysmal (ad-hoc authentication is probably implicated in a plurality of all major incidents).
- mdeeks 4y ago
  Probably the main concern around Google is for personal accounts where it sounds like people often find no way of recovering their accounts when Google thinks you did something bad. For business users that isn't as much the case since there are good support options and it isn't likely you'll get locked out. Great for businesses, potentially risky for individuals.
  - tptacek 4y ago
    This seems entirely fair to me. I mean, if you're scared of Google, you can use something like Okta. If it's me choosing, it's not a hard decision: I want centralized authentication, so I can quickly do blanket interventions like enabling/disabling apps, requiring phishing-proof MFA without having to do any implementation work, and linking everything to onboarding/offboarding/access review policies. And if I'm going to trust anyone's security team with this, it's going to be Google's.
- mike_d 4y ago
  > it's also worth knowing that SSO is basically a universal best-practice for security teams It is also best practice that some things explicitly don't sit behind SSO for defense in depth. If for example you leave CrowdStrike and JAMF behind Okta, and Okta gets popped an attacker can disable your endpoint protection and push ransomware to every machine.
api 4y ago
Totally meta to this discussion: I am disturbed by the SSO/IAM trend because it gives root on the entire universe to a small collection of companies. We are looking at a future where a security breach or misbehavior by one of a handful of companies could mass-compromise millions of businesses and critical infrastructure and possibly hundreds of millions to billions of devices. Even worse this permission is clandestine. It could be exercised against individual targets with no obvious audit trail, since auditing tends to also be delegated to the IAM provider (and nobody looks at local logs in most cases). I guess we've been handing vendors a lot of power for a while with OS vendors that have "push" software update capability, but this is adding not only even more carte blanche permission to a small number of companies but extending it across systems running different OSes and even open source platforms like Linux and BSD. Software update capability is also fairly coarse grained. Apple or Microsoft could push a compromised or malicious update, but it would be harder for them to specifically target a single user reliably and without being noticed. (Wait... why did I get a macOS update and none of my friends did?) SSO/IAM providers could easily do this. Imagine a subpoena that targets your SSO/IAM provider that gives the government (and maybe not even your government!) silent unlimited remote access to everything you have. I can also imagine "cancellation" scenarios where a company doesn't like what you say so they dump your account and lock you out of all your infrastructure, requiring you to manually go around and "root" all your stuff. (If you think this would only ever be deployed against Nazis, study history a bit. Political winds shift.) It's just a monstrous amount of power to give out, and I feel like people aren't thinking this through or maybe are not even aware of the power they are delegating. I feel like people should at least understand what they are doing when they choose to delegate all their authentication to Google.
- stavrianos 4y ago
  I've seen this conversation before, but I've never been clear on what exactly the consequences of the SSO are. I imagined, it might be that the provider gets an IP address when you connect or something. You're saying they potentially get _access as you_? Am I understanding that correctly?
  - api 4y ago
tlrobinson 4y ago
> goofy login flow Can you be more specific about your complaints?
- RL_Quine 4y ago
  I edited the original to contain more detail as I posted it but it seems to have been lost somehow. The login flow for Tailscale is weird due to the need to accommodate things like a headless server being added, when combined with their use of SSO as the only method of authentication things get confused very easily. When I add a new server I get given a URL that looks like https://login.tailscale.com/a/c44a243b https://login.tailscale.com/a/c44a243b to visit in a browser and authenticate the new device, the meaning of which is quickly lost as soon as you go through a Google Authenticator sign in flow, fill out some recaptchas and find your phone for a SMS token, and then the device is added to your account with no further clicks (unless you enable device authorization). It feels very weak, the connection between logging in and performing an action is fuzzy. Due to the use of Google SSO it just has the usual problems that you get. It's not quite clear when you're logged in or not or with which of the 12 google accounts you own, it's not clear what will pop 2FA requests or login prompts. As a service tailscale has made it clear that they don't want to be an "identity provider", which means you're sort of stuck with something that doesn't feel like you can make authoritative decisions about how it acts.
  - mike_d 4y ago
    > which of the 12 google accounts you own Stop logging in to your personal accounts on your work machine.
  - mdeeks 4y ago
    SSO is not the only method of authenticating things. They have auth keys specifically for the purpose of authing headless servers. e.g. sudo tailscale up --authkey tskey-abcdef1432341818 You can also apply an ACL tag to it so that it is no longer authorized as the user and instead takes on the permissions of the tag. In our deployments we have the headless servers pull the tagged auth key from secrets manager on boot and then just `tailscale up --authkey <value>`. I agree the default login flow is usually not what you want for headless servers. It sort of leads you down the wrong path.

It's helpful for people to know, from context later in the thread, that one of the core concerns behind this comment is the idea of using SSO at all, and thus giving "the keys to the kingdom" to Google. Of course, it's also worth knowing that SSO is basically a universal best-practice for security teams, and while it's not de jure required by SOC2, it's almost de facto required. For once, I think the best-practices and compliance people have this one right: you are extraordinarily unlikely to get burnt for trusting Google in this instance, and the security track record of ad-hoc authentication is worse than abysmal (ad-hoc authentication is probably implicated in a plurality of all major incidents).

mdeeks 4y ago
Probably the main concern around Google is for personal accounts where it sounds like people often find no way of recovering their accounts when Google thinks you did something bad. For business users that isn't as much the case since there are good support options and it isn't likely you'll get locked out. Great for businesses, potentially risky for individuals.
- tptacek 4y ago
  This seems entirely fair to me. I mean, if you're scared of Google, you can use something like Okta. If it's me choosing, it's not a hard decision: I want centralized authentication, so I can quickly do blanket interventions like enabling/disabling apps, requiring phishing-proof MFA without having to do any implementation work, and linking everything to onboarding/offboarding/access review policies. And if I'm going to trust anyone's security team with this, it's going to be Google's.
mike_d 4y ago
> it's also worth knowing that SSO is basically a universal best-practice for security teams It is also best practice that some things explicitly don't sit behind SSO for defense in depth. If for example you leave CrowdStrike and JAMF behind Okta, and Okta gets popped an attacker can disable your endpoint protection and push ransomware to every machine.

api 4y ago

Totally meta to this discussion: I am disturbed by the SSO/IAM trend because it gives root on the entire universe to a small collection of companies. We are looking at a future where a security breach or misbehavior by one of a handful of companies could mass-compromise millions of businesses and critical infrastructure and possibly hundreds of millions to billions of devices. Even worse this permission is clandestine. It could be exercised against individual targets with no obvious audit trail, since auditing tends to also be delegated to the IAM provider (and nobody looks at local logs in most cases). I guess we've been handing vendors a lot of power for a while with OS vendors that have "push" software update capability, but this is adding not only even more carte blanche permission to a small number of companies but extending it across systems running different OSes and even open source platforms like Linux and BSD. Software update capability is also fairly coarse grained. Apple or Microsoft could push a compromised or malicious update, but it would be harder for them to specifically target a single user reliably and without being noticed. (Wait... why did I get a macOS update and none of my friends did?) SSO/IAM providers could easily do this. Imagine a subpoena that targets your SSO/IAM provider that gives the government (and maybe not even your government!) silent unlimited remote access to everything you have. I can also imagine "cancellation" scenarios where a company doesn't like what you say so they dump your account and lock you out of all your infrastructure, requiring you to manually go around and "root" all your stuff. (If you think this would only ever be deployed against Nazis, study history a bit. Political winds shift.) It's just a monstrous amount of power to give out, and I feel like people aren't thinking this through or maybe are not even aware of the power they are delegating. I feel like people should at least understand what they are doing when they choose to delegate all their authentication to Google.

stavrianos 4y ago
I've seen this conversation before, but I've never been clear on what exactly the consequences of the SSO are. I imagined, it might be that the provider gets an IP address when you connect or something. You're saying they potentially get _access as you_? Am I understanding that correctly?
- api 4y ago

tlrobinson 4y ago

> goofy login flow Can you be more specific about your complaints?

RL_Quine 4y ago
I edited the original to contain more detail as I posted it but it seems to have been lost somehow. The login flow for Tailscale is weird due to the need to accommodate things like a headless server being added, when combined with their use of SSO as the only method of authentication things get confused very easily. When I add a new server I get given a URL that looks like https://login.tailscale.com/a/c44a243b https://login.tailscale.com/a/c44a243b to visit in a browser and authenticate the new device, the meaning of which is quickly lost as soon as you go through a Google Authenticator sign in flow, fill out some recaptchas and find your phone for a SMS token, and then the device is added to your account with no further clicks (unless you enable device authorization). It feels very weak, the connection between logging in and performing an action is fuzzy. Due to the use of Google SSO it just has the usual problems that you get. It's not quite clear when you're logged in or not or with which of the 12 google accounts you own, it's not clear what will pop 2FA requests or login prompts. As a service tailscale has made it clear that they don't want to be an "identity provider", which means you're sort of stuck with something that doesn't feel like you can make authoritative decisions about how it acts.
- mike_d 4y ago
  > which of the 12 google accounts you own Stop logging in to your personal accounts on your work machine.
- mdeeks 4y ago
  SSO is not the only method of authenticating things. They have auth keys specifically for the purpose of authing headless servers. e.g. sudo tailscale up --authkey tskey-abcdef1432341818 You can also apply an ACL tag to it so that it is no longer authorized as the user and instead takes on the permissions of the tag. In our deployments we have the headless servers pull the tagged auth key from secrets manager on boot and then just `tailscale up --authkey <value>`. I agree the default login flow is usually not what you want for headless servers. It sort of leads you down the wrong path.