juanfont
Tailnet Lock Feature request
Feature request
The official Tailscale server introduced https://tailscale.com/blog/tailnet-lock/ feature. I think implementing this feature could protect my private tailnet from being accessed even if the hosting server was compromised or there were undiscovered vulnerabilities in my setup. The feature can further improve the security and privacy of our tailnets through cryptographic means.
Hi, I think that's not the priority now, plus adding this type of key is useful if you can't trust the server, but you can't trust the client, as you are using your own Headscale instance, if your server is compromised probably your clients are compromised too, because if you secure your network well the risk is almost none.
@loprima-l I'm afraid I can't follow you. Would you mind rephrasing your comment?
Back to the topic at hand: I agree with @lyc8503, Tailscale Lock would be great. Otherwise, IIUC if the Headscale server gets compromised, the entire Tailnet will be, too. (Unless, of course, you've deployed further authentication measures beyond Tailscale.)
My point is : Yes it'll be an enhancement. But Headscale is not actually suitable for a sensitive environnement, and even if the point is to avoid security issues, securing more the product is not the current step. We can't take tail scale as an example, they introduced it only recently.
Maybe this would be a nice feature when Headscale is stabilized as for now the performances don't made it suitable for a large/sensitive environment. Headscale is fun to experiment or if you don't actually have the choice, your network shouldn't be exposed only by connecting to your instance, it's always necessary to have a secure infrastructure at all the levels.
I might do this at a later stage, as I am very curious about the implementation of Tailnet Lock. Because of this curiosity-driven development, for the time being I won't be accepting contributions on it.
Please consider Tailscale's SaaS if your use-case really requires this kind of security feature.
@juanfont So, a year and a half later, are there any plans to implement this critical feature in the near future?
And it is really important, because in a private network, where all devices do not have a public IP and access from the outside, the coordinating server is the most vulnerable part. Moreover, many people have it located in a VPS (https://github.com/juanfont/headscale/issues/1072 ) that have root access to all their virtual machines. Without the ability to sign nodes, the network is completely open to the VPS provider and all his "friends", not to mention the possible hacking of the server itself through any vulnerabilities.
If you are still not ready to implement it yourself, maybe you will give it to contributors?
@nokados I have to admit that some of my (happy) life events prevent me from spending time on this.
If anyone is interested, please proceed with a design doc proposal + subsequent implementation? 😄
Glad to hear your having good life events, hopefully someone can take this up as its a huge missing feature currently for headscale
A response to:
a huge missing feature currently for headscale
and
are there any plans to implement this critical feature in the near future?
I think this is a bit exaggerated, Tailnet Lock is a featured designed by Tailscale to be able to not trust that the managed service as they do not allow you to self-host.
Since Headscale is a self-hosted service which you deploy on your own infra, the whole idea is that you use it because you trust yourself.
The complexity of the feature and more importantly the risk and impact of it being implemented wrongly means that having some random contributor would be quite concerning to me. I do not think I (nor Juan) is knowledgeable enough on these kind of topics to even review such a contribution.
Anyways, we would of course not block such a contribution, but I cannot really imagine how we would be comfortable reviewing and accepting it and all the responsibility that entails.
My personal opinion is that I think in general that the need for this feature is exaggerated in this thread and if you do not trust your own infra, then that seem like a problem to tackle before needing this feature.
if you do not trust your own infra, then that seem like a problem to tackle before needing this feature
I use Google Cloud Platform myself and I trust their VPS, the probability of an infra being compromised is really low when configured correctly. But as someone mentioned above, it is possible that some people are using VPS products from unknown/suspicious vendors for hosting tailnet for budgetary reasons. (For the price of a one-month VPS at GCP you can buy a one-year VPS with the same performance at these vendors.) If we can put all the trusts on the client, we can confidently deploy Headscale anywhere, without having to constantly worry about “will my hosting provider access / hack into my private network”.
The complexity of the feature and more importantly the risk and impact of it being implemented wrongly means that having some random contributor would be quite concerning to me.
I agree with you, it's annoying to have to rebuild the whole tailnet if I get locked out due to a configuration/implementation error. Perhaps the risks of doing this could be stated in the documentation, or label it as a BETA feature at first.
My personal opinion is that I think in general that the need for this feature is exaggerated in this thread and if you do not trust your own infra, then that seem like a problem to tackle before needing this feature.
(emphasis mine)
The whole point is that Tailnet Lock would allow one to tackle the problem of not trusting one's own infra. :)
Either way, I think the Lock feature would be very valuable since the security implications of an attacker taking over the Headscale server could be quite severe from what I've been able to tell? (Related: https://github.com/juanfont/headscale/issues/1432)
This is a very important security feature. I hope some contributors can support this feature. I appreciate it very much.
The complexity of the feature and more importantly the risk and impact of it being implemented wrongly means that having some random contributor would be quite concerning to me. I do not think I (nor Juan) is knowledgeable enough on these kind of topics to even review such a contribution.
Anyways, we would of course not block such a contribution, but I cannot really imagine how we would be comfortable reviewing and accepting it and all the responsibility that entails.
From what I've figured while reading through the whitepaper the entire point of Tailnet lock seems to be that this is mainly a thing bootstrapped and enforced by the nodes while the control planes only role is distributing updates signed by the nodes, the verification magic has to happen at the client level. Tailnet lock builds on AUMs (Authority update messages). These are in essence comparable to signed git commits that contain info which public keys are allowed to be in the Tailnet and which TLKs (tailnet lock key, each node has their own for signing AUMs) are allowed to author/sign "commits". A AUM will only be accepted by a node if it is signed by a TLK that the was listed as a trusted key in the previous AUM.
Basically it looks like we just have to make the control plane be able to distribute AUMs, everything cryptographically more complicated that happens with those AUMs should be handled by the nodes/clients (for which Tailscale Inc. already does provide secure implementations).
Say if someone wanted to reverse engineer how the AUM distribution works and hack that into headscale for testing purposes, what would be the most efficient way to reverse engineer Tailscale for that? MITMing network traffic?
I can see about building this. I'll need some guinea pigs to try out the feature on windows and iOS though.
The point of self-hosting is indeed that you trust your own infrastructure more than other service providers. Moreover, the point of using VPNs or VPN-like products is to keep your infrastructure behind firewalls.
Headscale by necessity needs to be publicly exposed, and so, by necessity it is much more exposed and vulnerable than other services. Therefore, whether Headscale is hosted in a DMZ inside your infrastructure or a VPS (which is a respectable place to host such a service), Tailnet Lock is useful and arguably necessary feature. Many ISPs also use CGNAT which is another use-case that Tailscale/Headscale is designed to help with, which makes the use of VPS a requirement (or pay extra for a dedicated IP).
Either way, there are legitimate reasons why people may need the additional security that Tailnet lock provides, either because they host the Headscale server outside of their infrastructure, or in an inherently less secure DMZ.
Just to step in here: I would love to use Headscale over Tailscale, but since tailnet lock is not available i will not use it. Sadly, since its free, this is not an agument for the developers to implement it, but just to show how important the feature is for some people.
I want to trust the devices in my home not the device in someones datacenter.
Hello everyone,
It has been over two years since this feature request was opened, but the value of a Zero Trust control plane remains high.
I would like to request a re-evaluation of this feature's feasibility. To facilitate this, I have prepared a technical specification for a "lightweight" implementation. The proposed architecture minimizes server-side complexity by adopting an "Agnostic Storage" approach - delegating validation logic to the clients and treating Headscale primarily as a reliable transport for TKA messages.
Please find the design document attached for a quick assessment of the implementation complexity: Headscale-Tailnet-Lock-Design_Implementation.pdf
Thank you for your time and for all the hard work on Headscale!
