[akerl_]

I’m still trying to square the concept of “zero trust” here. The private keys never leave my devices, but the TailScale service is responsible for distributing public keys (which is what makes network access possible between my new system and another system).

If I’m understanding correctly: I open the TailScale app on my device, and auth to the TailScale platform using SSO. My device makes a private key, and sends my public key to TailScale. In the default mode, the TailScale platform gives me back the pub keys for other devices in my network, and gives my pub key to those devices. In the optional mode, an admin has to go into the TailScale platform UI and approve my device.

If that’s correct, in both modes, TailScale could compromise my traffic by making their own keypair and doing the pub key sharing process. Because it’s TailScale that’s responsible for validating my SSO before accepting my pubkey, and it’s the TailScale platform admin interface that’s responsible for deciding that an admin approved my device (if that feature is enabled), TailScale can just inject their own pubkey into my network. Am I missing something? Because that would be the opposite of “zero trust”.

[crawshaw]

Your analysis is correct, your machine has to trust the Tailscale auth server. I think that this is compatible with the technical definition and spirit of Zero Trust. To elaborate:

In the typical web-only BeyondCorp scenario, a network is Zero Trust because every connection is done over TLS and clients are validated by client-side certificates. These client-side certificates are not hand-typed by administrators into computers, instead they are trusted because they are signed by a CA root. "Zero trust" means zero trust in the network wires, all identity is confirmed with some sort of cryptographic certificate.

In the Tailscale model, a node trusts the Tailscale auth server because it presents a trusted certificate, and so is trusted to distribute endpoint public keys. A compromised Tailscale auth server compromises the network, in much the way a compromised CA root compromises an mTLS network.

For larger customers we are planning a self-hosted version of our auth server (so we are out of the trust loop), and want to publish the protocol we use for communicating with it for general inspection.

(Tailscale cofounder.)

[akerl_]

Interesting. If you’re actually using “Zero trust” to attempt to convey “zero trust architecture”, in the BeyondCorp sense, I’m more confused than before.

The central premise of BeyondCorp and similar approaches is about no longer trusting based on network location, and instead always performing trust based on device identity and other factors. This is why PKI plays such a pivotal role in BeyondCorp: your organization’s CA signs certificates, which are present on every device, and that combined with additional forms of user authentication enables trust regardless of network location. Leveraging a WireGuard VPN is largely a step “backwards”; it moves back towards a VPN-style world where you allow access by requiring endpoints to step inside a conceptual network boundary (by connecting to the VPN). In practice, the Wireguard model has several advantages over that, but it’s explicitly different from the BeyondCorp/Zero Trust approach.

Edit to clarify:

“Zero trust architecture” doesn’t refer to whether endpoints trust a central service/provider, it refers to whether corporate assets base their trust determinations on the origin point of client traffic. For example, in a non-Zero-Trust environment, corporate assets might assume clients connecting from the local network are trusted, and require roaming users to VPN in. By contrast, a Zero-Trust environment might use MDM-provisioned certificates and MFA on all connections, regardless of the network placement of the endpoint.

“Zero trust” as colloquially used by service providers tends to mean “you don’t have to trust us”. This is largely because “zero trust architecture” doesn’t really make sense as something a provider provides, and also because providers have latched onto “zero trust” as a buzzword.

[crawshaw]

I have not heard the colloquial use of "zero trust" by service providers you mention. The baseline Tailscale product is not "you don't have to trust us" as we run the auth server. The variant of our product where you run your own auth server does have this property, but it is not the default arrangement.

We do use "zero trust" in what you describe as the architectural sense, and I do not think leveraging WireGuard is a step backwards at all. When one node wants to communicate, it establishes a WireGuard tunnel to the node it wants to talk to. That WireGuard tunnel only moves packets for talking to a single node, to talk to another node you establish a new tunnel.

There is (in our default and recommended setup) a 1-1 relationship between a public key for an endpoint its IP address. That public key was linked to a corporate SSO account by the auth server. That means when you send or receive a packet from the private IP range Tailscale manages, you know exactly the identity of the source or destination of that packet.

If you configure a Tailscale node to route a subnet, you remove some of the BeyondCorp-style Zero Trust from your configuration. This feature exists to help companies transition to Zero Trust, and is not something I want to see as a final state for anyone's network. The end goal is Tailscale running on every node in the network.

[doublerebel]

> If you configure a Tailscale node to route a subnet, you remove some of the BeyondCorp-style Zero Trust from your configuration. This feature exists to help companies transition to Zero Trust, and is not something I want to see as a final state for anyone's network. The end goal is Tailscale running on every node in the network.

If the goal is to not use Tailscale as a standard SDN, and instead run it on every node with independent tunnels between nodes, when would I pick this vs using a service mesh that includes service discovery?

Is Tailscale intended to be a service mesh for the average Joe?

When creating an SDN or mesh, it's often preferable to separate local nodes (e.g. same datacenter) from remote nodes (e.g. different regions). How does Tailscale handle widely varying latency across the mesh?

[crawshaw]

That is a really good question. I like the line "service mesh for the rest of us." But I want to take the time to get this side of the product right, so the service discovery features we have been working on will be rolling out slowly.