Seems a bit like TINC-VPN
How Tailscale Works
31–40 of 82 posts
Re: How Tailscale Works
#32Earlier quoted context omitted.
Tunnels are created between any two devices that try to talk. It scales great, not concentrating connections makes it easy. Tunnels are very lightweight and the only machines with lots of tunnels are servers that are already provisioned for talking to lots of machines. (Tailscale co-founder)
Interesting :) Follow up, trying to cement my understanding here. If two devices may talk to each other (as defined in the ACL), only then they get to know each other's public keys, right? If so, how would this ACL be negated later- do the devices forget eachother after this disallow?
Yes, you only get the public keys of machines you can talk to. Later the server asks the client to forget the key if they can no longer talk.
Additionally, we rotate keys. For security sensitive users we can rotate these keys daily.
Re: How Tailscale Works
#33Thanks for the blog post. I am following the project closely since Brad announced working for you.
My main concern currently is the coordination server which does not fit the zero trust claim.
I know that the traffic between peers is end-to-end encrypted and you did a good job designing your DERP protocol. However, the ability of the coordination server (login.tailscale.com) to add arbitrary nodes to my private network without my consent scares me.
Maybe you can use Wireguard's PSK to add an additional pre-shared-key to all nodes that is not managed by the coordinator (and never transferred to it)? This would make the setup slightly more difficult (you need to login to tailscale.com AND you need to provide your PSK), but it would at least ensure that the system can never talk to foreign nodes added by the coordinator itself (because the foreign nodes do not know the PSK).
If you already use the PSK for something else, another passphrase/key-file that is never transmitted and is XOR'ed over the PSK will do the trick. The firewall configuration that is pushed to all clients should be probably signed by a local key too, since it is rather critical.
Another possible attack of the coordinator would be if he pushes a configuration with correct VPN IPs and correct public keys, but changes the mapping between them. Since the IP within a wireguard network is usually used as an identity, this might be a huge problem.
Re: How Tailscale Works
#34Any else getting a 500 on the blog?
Re: How Tailscale Works
#35Any else getting a 500 on the blog?
Working now after 3/4 tries
Re: How Tailscale Works
#36Any else getting a 500 on the blog?
Down for me as well
Re: How Tailscale Works
#37500 internal server error
Re: How Tailscale Works
#38Earlier quoted context omitted.
what's local networking got to do with gmail?
There needs to be a mechanism to distribute keys to nodes / authenticate nodes / associate nodes. Tailscale offers a centralized server to allow nodes to provision themselves. It bootstraps that trust/account system of of logging in with some account, such as via a google oauth login.
Right! That makes sense, thanks.
Re: How Tailscale Works
#39Thanks for the blog post. I am following the project closely since Brad announced working for you. My main concern currently is the coordination server which does not fit the zero trust claim. I know that the traffic between peers is end-to-end encrypted and you did a good job designing your DERP protocol. However, the ability of the coordination server (login.tailscale.com) to add arbitrary nodes to my private netwo…
Well, this just listed out my concerns pretty well and I spent the last hour installing this on my devices. Specifically, how do I explain to a fortune 500 IT department how this is secure in a few simple sentences?
Re: How Tailscale Works
#40A more relevant question for me is What is Tailscale? Didn't get that from either the article or really from the start page. Is it a VPN with "networking features"?