Today, we’re happy to announce that Tailnet Lock is generally available.
Tailnet Lock started with a simple idea: What if you could use Tailscale without having to trust Tailscale?
From scrappy startups and personal home labs to security-sensitive enterprises, thousands of tailnets have used Tailnet Lock to move Tailscale’s coordination server out of their center of trust. Today, we're making it official. Tailnet Lock is stable, hardened, and ready for production use.
Trust us, you don’t have to
Tailnet Lock lets customers control which nodes are signed and verified for access by trusted “signing” nodes in their tailnets. This ensures that they don't need to trust the Tailscale coordination server for distributing public node keys to peer nodes in their tailnets. Customers can control which nodes are trusted to sign another node's public key. When nodes join the tailnet and are not signed by a registered signing node, they don’t get network connectivity to any tailnet resources.
Tailscale’s coordination server can add and remove nodes from a tailnet, and customers sometimes see this as a potential threat vector. Tailnet Lock largely mitigates the risk of Tailscale suddenly becoming a threat actor by requiring customers to sign new additions to the tailnet with a trusted device. Tailnet lock follows a “Trust On First Use (TOFU)” model, where customers must initially “trust” Tailscale’s coordination server, but after setup, can move centers of trust into their network.
Get on the Lockchain
Tailnet Lock primarily consists of two components:
- Signing Nodes, which are nodes that can be used to sign new nodes onto the tailnet. With Tailnet Lock enabled, all nodes have an additional set of keys called Tailnet Lock Keys (TLKs). TLKs are generated by every node on first startup, but not every TLK needs to be trusted. Signing nodes are simply nodes with trusted TLKs, and this trust is recorded in the Tailnet Key Authority.
- The Tailnet Key Authority (TKA) is a subsystem running within each node on the tailnet, and stores changes to the current set of signing nodes in a cryptographically verifiable chain. TKA’s chains are append-only, via Authority Update Messages (AUMs) and all nodes can verify that only authorized updates are made to the chain. Internally, we sometimes call it the “lockchain” (sorry).
We recommend redundancy in Signing Nodes (up to 20 per tailnet) and a yearly rotation of TLK keys on those nodes. For more details, take a look at our white paper and our introductory post on Tailnet Lock.
TOFU
You still trust us once—but only once. The Trust On First Use model lets us help you set up your tailnet, but after your signing nodes are registered and your disablement secrets are securely stored by you, Tailscale can no longer sign new nodes onto your tailnet. On subsequent device additions, Tailscale’s coordination server sends the current state of signing keys to the new device, in the form of a cryptographically verifiable chain from the TKA via a Genesis AUM.
In theory, a compromised Tailscale control plane could send down a malicious initial state to attacker-controlled TLKs, allowing the threat actor to sign nodes on your behalf. Similarly, if an attacker-controlled TLK is trusted, the Genesis AUM sent to each node would include that attacker’s TLK. We think this is a fair tradeoff. Most customers set up Tailnet Lock early in their tailnet’s lifecycle. This model makes the initial process much simpler.
Self-hosting
You could alternatively host your own trusted control server with Headscale. This path removes the availability guarantees and low maintenance overhead that Tailscale’s software as a service (SaaS) model provides. Customers who want to keep the center of trust on their networks while still subscribing to the benefits of a Tailscale-maintained control plane can look to Tailnet Lock.
What’s new
We’ve heard plenty of feedback from customers over the years (thousands of you), and we’ve implemented a lot of that to bring an improved experience.
Webhooks
At smaller scales, it’s easy enough to manage new additions to the tailnet and kick off signing processes. At larger scales or when trying to build in explicit automations, customers need a messaging system to sign their new nodes. For key lifecycle events (pending signature, signed, registered), we’ve introduced new webhook events that let you automate the signing of new nodes, implement alerting, and build an audit trail.
Disablement secrets stay private
We used to recommend that customers share a disablement secret with our support team. This helps us help you, in case you lose your disablement secrets, or need help disabling Tailnet Lock. Many of our customers have robust secret storage and don’t want to share their secrets with us.
With that in mind, Tailscale no longer defaults you to sharing your disablement secrets. You hold the keys, which means Tailscale can’t disable Tailnet Lock on your behalf — but if you want to trust us as a backup, feel free to enable a key for our support team when you set up Tailnet Lock.
Safeguards
You can’t remove all signing nodes by mistake. We’ve seen a series of reports where a customer has accidentally removed the last available signing node on their tailnet, effectively forcing that tailnet into a static state. We now prevent users from removing the last remaining signing node until another one is available, but we do recommend redundancy in these nodes.
Try it today
If you’re interested in how it all works, take a look at Tailnet Lock and get started today. If you’re an organization that wants complete control over your boundary of trust and you’d like to implement Tailnet Lock, please contact our sales team.
Kabir Sikand
