Isn't the tailscale work more to do with authenticating hosts than the network. You trust all communication decodable by a trusted public key.

That still allows malware on a trusted end device to connect to you, but then if you've got malware on the box chances are it will have access to the private keys, authentication cookies etc, anyway - at least currently.

I guess in an ideal world where everything in your org is behind MFA, app authentication and protected from denial of service, then solutions like tailscale would not be needed.

But my personal experience is that most software is completely hostile to good security practices and you end up having some perimeter security as well.

Someone else mentioned that basically malware on your machine is expected to bypass all security layers. So we’re basically saying “the ‘new’ network layer is now as trustworthy as the app layer” rather than claiming everything is perfect, you’re right.

This is one reason we limited taildrop to only transfer between devices owned by a single user for now, and only to drop files into controlled locations. Tailscale also has ACL policies for when you don’t trust all the endpoints to just do anything.

There is ACL support on the Admin console.

Lets you choose which users/machines/tags can talk to who. Tags are like groups.

The localapi is indeed an http server built into the tailscaled process, which is written in Go. Since we already had an http client in there, the net new code to add an http server is quite low. And it doesn’t take any battery unless it’s being queried. I think people underestimate how cheap http can be (once you’ve paid the up front cost, anyway).

You’ve correctly guessed that blog link [0] that explains the reason I don’t think we’d ever want to try making a distributed coordination service. Most importantly, corporate customers absolutely love having a single control and registration point for every corporate authorized device on their network (and thus, a way to instantly deauthorize stolen devices). What we’re going to do though is add private audit trails and tamper proofing, kind of like TLS certificate transparency, so that the central instructions can be validated in a decentralized way, if that makes sense. More on that later. :)

Re: peerapi, there are lots of ways to build app layer protocols once you have tailscale making the connection itself easier. We picked http since it was the fewest lines of code and it makes an easy example.

Re: live video, Jitsi already works fine on a tailscale network if you want to try that.

In Tailscale, much like in SDN or SD-WAN, we think of the network in two parts, the control plane and the data plane.

The data plane is how the bulk of your packets get sent from one place to another, which in Tailscale is peer-to-peer (as long as your network is not completely blocking NAT traversal for some reason). Even if NAT traversal is blocked and we have to relay your data through the cloud (through our DERP network) to make it work, the data plane is still end-to-end encrypted using private keys that only exist on each node. The private keys never leave each node. The DERP servers are just relaying opaque byte streams, like any IP router would do.

On the other hand, the Tailscale control plane uses a central coordination service. It's used to exchange public keys and STUN information between nodes, but this is a tiny amount of information updated rarely (and therefore reasonably cheap for us to handle at scale). These public keys are not enough for an attacker (us or anyone else) to be able to decrypt your data traffic.

So when we say taildrop never sends your files through the cloud, that's because taildrop exists entirely inside the data plane, sending data through e2e encrypted tunnels that have already been established with the help of the coordination service, STUN, etc.

Because the coordination service is cheap for us to run, we can have a really generous Tailscale free plan without losing all our money. The paid plans are intended to be for "corporate network" situations where people want more centralized controls, audit trails, and so on.

MacOS, iOS, and Linux clients can use your native OS updates. Windows needs to be updated by hand or with something like chocolatey or MDM. But more importantly, we have a policy of not breaking old clients if we can possibly avoid it. So far we have never deprecated old clients. We extend our protocols in a backward compatible way, because unilaterally breaking your network infrastructure… really sucks.

The way tailscale networks (tailnets) work is probably not how you’re used to thinking about them. Each node has its own view of the world, based on which nodes and services are shared with it in particular. We have security policy settings per domain, and a node sharing UI that lets you share any of your devices with anyone else.

The default model is that all devices belonging to someone in the same domain, say tailscale.com, can see each other. But we’re working on making that even more flexible since it doesn’t always do what you want for huge orgs (like universities).

Found the answer, in the headscale readme:

> Everything in Tailscale is Open Source, except the GUI clients for proprietary OS (Windows and macOS/iOS), and the 'coordination/control server'.

Keeping the GUI clients for proprietary operating systems closed-source is certainly a valid business decision. It's just unfortunate that it means we don't get to fix any issues we find that may matter more to us than they currently do to the Tailscale team, e.g. accessibility.

Edit: Yes, I know, to be fully consistent on this point, I should run an open-source OS. But then, the proprietary operating systems have accessibility teams, while presumably Tailscale does not.