They're the same as the implications for using something like Okta as your source of truth for authentication, and Okta is ubiquitous in large enterprises.

It's not not a concern, it is something you can think about and work out how to mitigate, but the benefits to their product of Tailscale hosting the control plane are going to outweigh the objections.

Agreed, one way to help mitigate this is to establish Layer 7 security controls, rather than implicitly trust the network. Tailscale shouldn't be the sole security control in any environment.

I pretty much agree. Tailscale makes this pretty easy: you get role-based default-deny port-granular ACLs, so it was easy for us to establish a regime where we're only exposing HTTP-type services, on specific machines rather than whole swathes of address space. We then require SSO logins on those services (which in turn enforce things like 2FA).

Just getting access to our Tailscale networks doesn't get you anything; having your account in a group with access to an application gets you the right to attempt an SSO login to it and nothing else.

Yes, this is a real concern. No matter how good tail scale guys are, their control plane services become super attractive target for attackers (solar wind style attack). Tailscale could provide a "Github Enterprise" style on-prem deployable control plane services running on enterprise controlled domain and with its own BYOK infra. This would majorly address the concern.

FWIW, we do sell an on-prem version to certain customers. It's not widely available anybody yet, but it exists.

(I work at Tailscale)

That's awesome. When it becomes widely available, I would be inclined to talk to my boss about it :-)

A generally available version of this would be a killer feature.

Tailscale doesn't, but there's another opensource project which does provide control plane: https://github.com/juanfont/headscale.

Even with a on-prem control plane, you probably want logging setup to detect when unusual nodes get pushed to the accessible list of nodes on your clients.

There is also Cloudflare Zero Trust (Teams), which is free for 50 users and accomplish the same thing (Wireguard = Tunnels), with a lot more years of "trust" and security behind it.

However, it's very cumbersome to setup, nowhere near as easy as Tailscale.

Cloudflare Zero Trust here: we're releasing significant improvements in the setup with Tunnels in a few days that addresses this exact kind of feedback.

We believe that our security, performance and integration with the rest of Cloudflare are already quite awesome. We're going to raise our usability by quite a notch with the news coming up. Stay tuned with blog.cloudflare.com

Please add an RSS feed to the Cloudflare blog. Much easier to read that way.

They have an RSS Feed, here:

https://blog.cloudflare.com/rss/

Thanks! My Fever feedlet failed to find it.

There's also HashiCorp Boundary, which deviates from the traditional VPN or jump box based approaches such as a VPC. https://www.boundaryproject.io/

And there’s BeyondCorp Zero Trust by Google. https://cloud.google.com/beyondcorp

Just deploy https://github.com/slackhq/nebula somewhere and voila - you have your own completely self-hosted version of Tailscale.

Wow I had not heard of this. Thank you for sharing. It says lighthouses are optional but recommended. Any idea how it can work without a lighthouse?

Haven't used, but I believe lighthouses are primarily for host discovery (dns) + hole punching. I think if you configure static hosts on all nodes you're good:

https://www.defined.net/nebula/config/#static_host_map

That's correct.

Yes nebula is amazing, I'm using it everywhere! I made a rest API to manage nebula lh, multiple networks, users, certs. All packaged as a docker image. And open-source of course: https://github.com/elestio/nebula-rest-api

You could run your own encryption on top of Tailscale; for web properties, you can use use Tailscale's HTTPS[0] via an ACME client (thus Tailscale doesn't see your HTTPS private keys) or SSH which is inherently encrypted and verified via host identification. For anything else I don't think you can manage it much, you've always had to trust your network operator for unencrypted/unverified traffic.

0: https://tailscale.com/kb/1153/enabling-https/

The concern is not encryption. Wireguard encrypts the traffic, and users could indeed verify this fact before traffic leaves their machines.

The concern is that, if an attacker (such as a government) compromises Tailscale, or Tailscale wants, they could probe your applications. It would be like your SSH being exposed to internet.

These products bypass firewalls, which is a good thing if they are secure, and a terrible thing if they are not.

There have been cases where the coordination servers have been (sometimes silently) compromised; see stories about encrypted phones. Users thought they were secure.

And unfortunately small companies may not have sufficient resources to secure their infrastructure against more resourceful adversaries.

That’s why it’s better to pay, so that the startups have funds to improve the product.

Would something like headscale (https://github.com/juanfont/headscale) solve that concern?

I think by "adding encryption", they mean using mTLS internally. Your application can request that the client authenticate the connection by presenting a certificate, your application then applies whatever validation it wants before allowing that session to do anything. If someone were to compromise Tailscale, they can open a TCP connection to your application, but your application will then reject the connection because it doesn't trust the certificate. That's "zero trust" as I understand it.

This is the direction I'd like to see networking go in general. Everything can have a public IP, but applications won't talk to anything that's unauthenticated. No more VPCs, VPNs, "kubectl port-forward", jumpboxes, etc. In practice, this is a colossal pain that nobody really knows how to do right. It requires rewriting all existing software, a secure way of issuing certificates (ideally not controlled by the cloud provider that runs your applications), and it can very easily fail open.

(I do mTLS for my personal projects, but my cloud provider can easily issue themselves a trusted cert and use that to poke around if they really wanted to. They own the machines that my CA runs on, so they are the root of trust. At some point, what you end up with is something that feels correct, but is in practice the same thing as just trusting Tailscale. The first 99% of security is making sure some rando on the Internet can't download your HR database and secret plans for world domination. The remaining 99% of security is making sure the NSA can't do that. Maybe you're OK with the NSA mucking about with your internal network, and in that case, you can save yourself a lot of trouble.)

Tailscale ACLs can prevent that.

This doesn't solve the problem it just shifts it so that the attacker also has to control ACL assignments as well as node creation.

My knowledge in this domain isn't deep, but..

Isn't the main alternative also an ACL, just in the form of a more course grained firewall? The idea of these networks AIUI is that some of the existing infra, such as firewalls and even application level encryption, are replaced by something that is subjectively easier to administer and monitor. Not saying it is better, just that's it's different. And if it's different, then it makes sense that the attack surface is different too.

Surely ACLs are controlled by the central authority (Tailscale), and not set on each individual device outside of the central authority's control. If so, then the whole ACL argument is moot because the threat model under consideration is that tailscale is compromised and attackers can modify the control plane.

You have to worry about attackers modifying the control plane regardless of whether it's under your control or Tailscale's. You do need to collect the logs of how the nodes allowed to connect are changing to your SIEM. Which should be already done, because they already shove the (extremely verbose) logs into the appropriate places (eventlog on windows, journalctl on linux)

Obviously you have to secure your control plane. The question is who is securing it. I would rather be segregated from other users so I'm not swept up in a breach in tailscale that can compromise every user at once. It's a big single point of failure.

My bigger issue is them adding hidden nodes that can potentially access my services. If I use Tailscale to provide (otherwise unauthenticated, since I've already authenticated to Tailscale) access to, say, a file server, a hidden node can just see all my files.

Isn't this where the ideas of zero trust networking come into play?

It doesn't matter that you've authenticated to the network, you still need to authenticate to the application. SSO and the like become increasingly important in this kind of world mind.

BastionZero is a similar product which gives you multiple roots of trust, one to BastionZero, and one to your identity provider (Google, Okta, etc.) https://www.bastionzero.com/security-model

I'm not worried too much about the client software because it's open source and can be built from source, at least on the desktop.

I mitigate the potential risk of a compromised control plane by using secure protocols on top of Tailscale. Namely SSH and HTTPS with a custom CA and proper authentication wherever possible.

OpenZiti and NetFoundry address by enabling you to close all your inbound firewall ports (and link listeners) such that even your OpenZiti (open source) or NetFoundry (SaaS) Fabric Routers can't initiate sessions into your network.

You could look into using tor hidden onions instead

Use headscale on your own VPS and that should quench the concerns you have.