←back to thread

345 points quyleanh | 1 comments | | HN request time: 0s | source
Show context
SuperShibe ◴[] No.43564441[source]
Every few months I come back to this repo to check if they finally got Tailnet lock running or if someone security audited them in the meanwhile. Unfortunately neither of these things seem to make any progress and thus, I’ve grown uncertain in how much I can trust this as a core part of my infrastructure.

The entire premise of Tailscale SaaS builds on creating tunnels around your firewalls, then enabling the user to police what is allowed to be routed through these tunnels in a intuitive and unified way.

Headscale seems to have nailed down the part of bypassing the firewall and doing fancy NAT-traversal, but can they also fulfill the second part by providing enough of their own security to make up for anything they just bypassed, or will they descend to just being a tool for exposing anything to the internet to fuck around with your local network admin? To me, not giving your Tailscale implementation any way for the user to understand or veto what the control server is instructing the clients to do while also not auditing your servers code at all sure seems daring…

replies(4): >>43564556 #>>43564684 #>>43564733 #>>43566920 #
bananapub ◴[] No.43566920[source]
tailnet lock seems way way less important for headscale than tailscale, given you personally control the headscale infra.
replies(3): >>43568117 #>>43569229 #>>43569423 #
1. SuperShibe ◴[] No.43569423[source]
only until someone finds a zeroday in headscale (remember, it never got audited) or until the server running headscale itself gets compromised. Especially in countries where getting a dedicated public IPv4+IPv6 from your ISP is hard-impossible and you‘d have to rely on a server hosted externally (unless you’re large enough to make deals with the ISP) some company hosting your server still retains at minimum physical control over your headscale infra. For why this is a problem, see the recent Oracle cloud breach.