6 ms·

I really want to like and recommend Tailscale more (and MagicDNS is another bonus) but with the forced use of Google auth and still no support for fast user swi

I really want to like and recommend Tailscale more (and MagicDNS is another bonus) but with the forced use of Google auth and still no support for fast user switching and connections to multiple networks, it just has too many dealbreakers for me and many colleagues. Zerotier has had all of that figured out for years, in the meantime Tailscale just locked the thread requesting multiple connection support as "too heated" (after >2 years of no progress). And putting access to our corporate networks in the hands of Google & Co. and their trigger-happy account-blocking algos means that TS gets an automatic thumbs down from compliance officers at several of our clients. We can read stories on HN every week why such authentication systems are a bad idea, and steadfastly refusing to roll your own account system (all the while justifying it with handwavy security concerns) just seems lazy to me. I can follow their arguments to some extent, I just don't understand why the TS people insist on exclusionary features rather than letting the user choose. You believe multiple simultaneous connections are somewhat insecure and that's why you won't implement it? Okay, slap a warning sign on it if you want, by all means, but who cares about this if all I want is to connect to 5 branch offices at the same time. You believe forcing users to use their private, everyday Google or Github accounts for authentication is safer than using a special account registered on TS with safe, unique credentials not used for any other purpose to minimze collateral damage (if the Google or Github credentials get compromised you'd get their emails or a bit of source code, but not access to the WHOLE corporate network)? How about letting the user choose and show some flexibility to use-cases that exist even if you can't imagine them? Sorry for the rant, again, I want to love TS, it's UX is pretty neat, but something about their supercilious attitude with which they justify their (non-)features just rubs me the wrong way, I guess. At the risk of downvotes (because I know TS has - rightfully - many fans), if anyone from TS is reading this, I do implore you to be more open-minded and give your users a choice rather than patronising them on multiple fronts when using your product. Feel free to recommend a "best practice" but understand that many users who might love your product will want and have to use it in a slightly different way than you intended - and that should be okay.

preseinger 4y ago
> I just don't understand It's an order of magnitude less effort and risk to defer auth to third parties via SAML/OAuth/etc. versus owning it yourself with email-based (or whatever) logins. That's it. Nothing more.
- imagine99 4y ago
  > It's an order of magnitude less effort and risk For the developer, yeah, not for the user though. But "least-effort development" is not generally that meritorious, especially in this area, and arguably a large part of TS's value proposition is about "less effort and less risk" for the user! For the user this means more effort and more risk if you consider that you've just multiplied your attack surface by combining internal, privileged access to your network (often without any firewalls or per-device authentication) with whatever other skimpy services you use the credentials for. I know we're all supposed to expect zero trust these days and have all these well-designed enterprise IdP systems in place but the reality is starkly different, especially in the SMB space. I know that there are a lot of things you can do wrong with auth but a company capable of developing something as complex as a zero-config modern mesh VPN should be able to handle rolling their own auth, come on. And by the way, it's not like they get the third-party SSO right either: Every time we log into the admin panel with our 3rd party (Microsoft/Github/Google) account, we are asked to re-authorize Tailscale ("Tailscale by Tailscale wants to access your data..."). In short, they could really throw some developer hours at this and polish it a bit, roll their own auth (again, can be a tertiary beta option with warning labels at first) etc. This would also leave a good first impression with first time and trial users, and, most importantly, give users an informed choice to leverage the solution that they consider the least effort and least risk for their use case.
  - PLG88 4y ago
    Fully agreed. Want you probably want is OpenZiti. It's a modern mesh overlay network which is explicitly built on zero trust principles including using strong embedded identity (with the ability to plug in 3rd party IdP). This ensures per-endpoint authentication and authorisation before any connectivity can be established on the basis of least-privilege and microsegmentation. The connectivity at source and destination is established outbound so no inbound ports are needed while providing private (magical) DNS. It's also completely open source and free. Here is an overview of some of the superpowers - https://www.youtube.com/watch?v=hLEeHit3prY&list=PLMUj_5fklasKF1oisSSuLwSzLVxuL9JbC&ab_channel=OpenZiti https://www.youtube.com/watch?v=hLEeHit3prY&list=PLMUj_5fkla... Disclaimer, I do work on the project so take me with a pinch of salt.
deleted 4y ago
[deleted]
nalllar 4y ago
> but with the forced use of Google auth There are two other options - MS and GitHub (does that only count as one?) - for free users.
BrightOne 4y ago
My tailnet is set up using a GitHub organization, without using Google at all. I have sufficient security (2FA with security keys, etc.) enforced for it. I think that hand-rolling their own auth would not be a great idea just yet, while they are still ironing out other features.
- ev1 4y ago
  The only choices being MS or Google for auth, both with trigger happy defence mechanisms, is kind of annoying though.
  - dijit 4y ago
    There are more options than that, and I see your point. To take the contrarian stance though: SSO not being paid is kinda nice, and not having yet another password for something is nice. —- double and: then not being able to leak a password or handle 2FA, instead focusing on their actual product.
    - ev1 4y ago
      For free users, it's pretty much just G, MS, and GH (which is currently the only "tolerable" one, but there's no reason why it won't turn into a MS account in the future just like how they killed Minecraft)
      - cadamsau 4y ago
        If GH accounts turn into MS accounts, that's a sure sign it's time to take your repos elsewhere, because the wrong people are in charge. Might mean a little more work to help reimplement GH features in the platform of choice. Not everyone will leave. But it'll be great for the diversity of the internet.
        GoOnThenDoTell 4y ago
        So 4 years tops?
tssva 4y ago
Microsoft, GitHub, Okta, OneLogin and custom solutions for enterprise customers are also available for authorization.
aaomidi 4y ago
It also really feels like tailscale is holding iOS hostage to reduce the users of headscale.
jonpurdy 4y ago
It took me six months to actually set up TS because of the lack of email/password auth. So this is definitely a pain point. It's such a good product that it's annoying that they don't roll their own simple auth. I eventually gave up and used Github and it's definitely been worth it for my personal use (a personal laptop accessing a Mac Mini in SF while on vacation, as well as setting up exit nodes on VPSs for getting around geo-restrictions).
andrelaszlo 4y ago
They don't support SAML? It's not the nicest standard, sure…
- jkaplowitz 4y ago
  Their Team and higher plans integrate with Okta, their Business and higher sync group memberships and deactivated users with Okta, and their "contact us" Enterprise plan supports custom SAML and OIDC. I think this is a fair tradeoff of cost vs benefit given who needs each solution and how much individualized time and energy Tailscale needs to spend per customer to support each of these solutions.
  - andrelaszlo 4y ago
    Yeah that makes a lot of sense. Given how the protocol is used in practice it does require a lot of support. I understood the parent comment as them only supporting Google.
    - jkaplowitz 4y ago
      They don't support TailScale-specific email and password accounts in any version, and only Google or GitHub login (or maybe MS accounts?) in the free version. That was the basis of the complaint, I think. TailScale has written separately about why they made that choice.
deleted 4y ago
[deleted]
tailspin2019 4y ago
I completely agree and judging by the upvoted position of your comment here, lots of other HNers do too. So I hope Tailscale do take note. I'm a Tailscale customer very reluctantly using their social/SSO login mechanism but to your point, I've already lost access to an earlier Tailscale account due to a screw up (long story) with some changes to the MS corporate account that it was linked to. I really really dislike forced usage of social/SSO logins and it's one of a couple of reasons I may move away from Tailscale at some point. Edit: Agree re. fast user switching and connections to multiple networks too - those would be extremely useful
wbl 4y ago
If you want to connect to multiple endpoints, use the ACLs. That's what they are there for. Multiple identities at once are a sign that something has gone terribly wrong in your organization's ability to manage access, and if it hasn't gone wrong yet it will.
- fiddlerwoaroof 4y ago
  This is completely ignoring the use case of “multiple organizations”. E.g. a contractor might need access to an agency’s network and a client’s network on the same device.
  - infogulch 4y ago
    So the client's network adds an ACL to allow the contractor (a member of the agency's network) to access their system?
- nijave 4y ago
  It is pretty normal to have multiple identities--especially if they're for different environments like development, test, staging, uat, etc
- jlokier 4y ago
  The very concept of "your organization" is not meaningful for some users. Even when working for a single client organization, I usually need VPN connections to my own servers at the same time - my own business is the second organization. Typically you start some consulting work for an organization, and they hand you an identity to use for the work. They won't use the one you have already or grant access via an ACL. They give you a new id (yes, a new Gmail address even for an 8 week contract, and you're supposed to check it). So you're consulting for 3 organizations this Q4, and you've been given 3 identities to use for VPN access. To actually be useful to them in your consultancy work, you need to connect to your own servers during the day as well. Being able to use those is key to what makes you valuable. Fast user-switching or even simultaneous login would be handy, and having to agree special arrangements with various IT departments is usually a lot of friction. Slow user-switching is what you end up having to do in practice, and that's a pain. I've had this with other VPNs when doing consulting jobs. Re-logging in via slow dialogs to their VPN 20 times a day, due to switching. I didn't know Tailscale had this restriction until the GP comment, as I have been avoiding Tailscale due to the social-SSO constraint. I was considering, reluctantly, trying it out with my GitHub credential, the one that I think I'm least likely to lose access to. (But consider that all Russian accounts were suspended abruptly this year.) But I do use multiple VPNs to servers under the control of different organizations through the day, so the switching constraint seems relevant too.

preseinger 4y ago

> I just don't understand It's an order of magnitude less effort and risk to defer auth to third parties via SAML/OAuth/etc. versus owning it yourself with email-based (or whatever) logins. That's it. Nothing more.

imagine99 4y ago
> It's an order of magnitude less effort and risk For the developer, yeah, not for the user though. But "least-effort development" is not generally that meritorious, especially in this area, and arguably a large part of TS's value proposition is about "less effort and less risk" for the user! For the user this means more effort and more risk if you consider that you've just multiplied your attack surface by combining internal, privileged access to your network (often without any firewalls or per-device authentication) with whatever other skimpy services you use the credentials for. I know we're all supposed to expect zero trust these days and have all these well-designed enterprise IdP systems in place but the reality is starkly different, especially in the SMB space. I know that there are a lot of things you can do wrong with auth but a company capable of developing something as complex as a zero-config modern mesh VPN should be able to handle rolling their own auth, come on. And by the way, it's not like they get the third-party SSO right either: Every time we log into the admin panel with our 3rd party (Microsoft/Github/Google) account, we are asked to re-authorize Tailscale ("Tailscale by Tailscale wants to access your data..."). In short, they could really throw some developer hours at this and polish it a bit, roll their own auth (again, can be a tertiary beta option with warning labels at first) etc. This would also leave a good first impression with first time and trial users, and, most importantly, give users an informed choice to leverage the solution that they consider the least effort and least risk for their use case.
- PLG88 4y ago
  Fully agreed. Want you probably want is OpenZiti. It's a modern mesh overlay network which is explicitly built on zero trust principles including using strong embedded identity (with the ability to plug in 3rd party IdP). This ensures per-endpoint authentication and authorisation before any connectivity can be established on the basis of least-privilege and microsegmentation. The connectivity at source and destination is established outbound so no inbound ports are needed while providing private (magical) DNS. It's also completely open source and free. Here is an overview of some of the superpowers - https://www.youtube.com/watch?v=hLEeHit3prY&list=PLMUj_5fklasKF1oisSSuLwSzLVxuL9JbC&ab_channel=OpenZiti https://www.youtube.com/watch?v=hLEeHit3prY&list=PLMUj_5fkla... Disclaimer, I do work on the project so take me with a pinch of salt.

deleted 4y ago

[deleted]

nalllar 4y ago

> but with the forced use of Google auth There are two other options - MS and GitHub (does that only count as one?) - for free users.

BrightOne 4y ago

My tailnet is set up using a GitHub organization, without using Google at all. I have sufficient security (2FA with security keys, etc.) enforced for it. I think that hand-rolling their own auth would not be a great idea just yet, while they are still ironing out other features.

ev1 4y ago
The only choices being MS or Google for auth, both with trigger happy defence mechanisms, is kind of annoying though.
- dijit 4y ago
  There are more options than that, and I see your point. To take the contrarian stance though: SSO not being paid is kinda nice, and not having yet another password for something is nice. —- double and: then not being able to leak a password or handle 2FA, instead focusing on their actual product.
  - ev1 4y ago
    For free users, it's pretty much just G, MS, and GH (which is currently the only "tolerable" one, but there's no reason why it won't turn into a MS account in the future just like how they killed Minecraft)
    - cadamsau 4y ago
      If GH accounts turn into MS accounts, that's a sure sign it's time to take your repos elsewhere, because the wrong people are in charge. Might mean a little more work to help reimplement GH features in the platform of choice. Not everyone will leave. But it'll be great for the diversity of the internet.
      - GoOnThenDoTell 4y ago
        So 4 years tops?

tssva 4y ago

Microsoft, GitHub, Okta, OneLogin and custom solutions for enterprise customers are also available for authorization.

aaomidi 4y ago

It also really feels like tailscale is holding iOS hostage to reduce the users of headscale.

jonpurdy 4y ago

It took me six months to actually set up TS because of the lack of email/password auth. So this is definitely a pain point. It's such a good product that it's annoying that they don't roll their own simple auth. I eventually gave up and used Github and it's definitely been worth it for my personal use (a personal laptop accessing a Mac Mini in SF while on vacation, as well as setting up exit nodes on VPSs for getting around geo-restrictions).

andrelaszlo 4y ago

They don't support SAML? It's not the nicest standard, sure…

jkaplowitz 4y ago
Their Team and higher plans integrate with Okta, their Business and higher sync group memberships and deactivated users with Okta, and their "contact us" Enterprise plan supports custom SAML and OIDC. I think this is a fair tradeoff of cost vs benefit given who needs each solution and how much individualized time and energy Tailscale needs to spend per customer to support each of these solutions.
- andrelaszlo 4y ago
  Yeah that makes a lot of sense. Given how the protocol is used in practice it does require a lot of support. I understood the parent comment as them only supporting Google.
  - jkaplowitz 4y ago
    They don't support TailScale-specific email and password accounts in any version, and only Google or GitHub login (or maybe MS accounts?) in the free version. That was the basis of the complaint, I think. TailScale has written separately about why they made that choice.

deleted 4y ago

[deleted]

tailspin2019 4y ago

I completely agree and judging by the upvoted position of your comment here, lots of other HNers do too. So I hope Tailscale do take note. I'm a Tailscale customer very reluctantly using their social/SSO login mechanism but to your point, I've already lost access to an earlier Tailscale account due to a screw up (long story) with some changes to the MS corporate account that it was linked to. I really really dislike forced usage of social/SSO logins and it's one of a couple of reasons I may move away from Tailscale at some point. Edit: Agree re. fast user switching and connections to multiple networks too - those would be extremely useful

wbl 4y ago

If you want to connect to multiple endpoints, use the ACLs. That's what they are there for. Multiple identities at once are a sign that something has gone terribly wrong in your organization's ability to manage access, and if it hasn't gone wrong yet it will.

fiddlerwoaroof 4y ago
This is completely ignoring the use case of “multiple organizations”. E.g. a contractor might need access to an agency’s network and a client’s network on the same device.
- infogulch 4y ago
  So the client's network adds an ACL to allow the contractor (a member of the agency's network) to access their system?
nijave 4y ago
It is pretty normal to have multiple identities--especially if they're for different environments like development, test, staging, uat, etc
jlokier 4y ago
The very concept of "your organization" is not meaningful for some users. Even when working for a single client organization, I usually need VPN connections to my own servers at the same time - my own business is the second organization. Typically you start some consulting work for an organization, and they hand you an identity to use for the work. They won't use the one you have already or grant access via an ACL. They give you a new id (yes, a new Gmail address even for an 8 week contract, and you're supposed to check it). So you're consulting for 3 organizations this Q4, and you've been given 3 identities to use for VPN access. To actually be useful to them in your consultancy work, you need to connect to your own servers during the day as well. Being able to use those is key to what makes you valuable. Fast user-switching or even simultaneous login would be handy, and having to agree special arrangements with various IT departments is usually a lot of friction. Slow user-switching is what you end up having to do in practice, and that's a pain. I've had this with other VPNs when doing consulting jobs. Re-logging in via slow dialogs to their VPN 20 times a day, due to switching. I didn't know Tailscale had this restriction until the GP comment, as I have been avoiding Tailscale due to the social-SSO constraint. I was considering, reluctantly, trying it out with my GitHub credential, the one that I think I'm least likely to lose access to. (But consider that all Russian accounts were suspended abruptly this year.) But I do use multiple VPNs to servers under the control of different organizations through the day, so the switching constraint seems relevant too.