headscale
headscale copied to clipboard
juanfont
Toggleable /swagger, /windows and /apple endpoints
👋 Hi!
Although /windows and /apple may not disclose a lot of data, I'm a bit worried about /swagger and its exposure open wide on the general listening port.
I'd suggest making these endpoints toggleable by configuration
Is it to prevent from security vulnerabilities on the unmanaged swagger code ? Even though the API is here doesn't mean that anyone can manage the Headscale server. You would still need a valid APIKey.
Hi!
Is it to prevent from security vulnerabilities on the unmanaged swagger code ?
more than that, I don't see any reason to have a swagger endpoint exposed open wide. (But I could be missing something here!)
I suppose it makes some overview of an attack surface visible.
However, I dont really want to start solving a problem with togglable endpoints for the sake of it.
What I think would be more sensible is to have it authenticated. I can imagine a solution were it is only available if you use oidc, and if oidc is enable, all those endpoints requires login.
I argue that if you don't use oidc, you run a small enough deployment that this does not matter.
it's a fair point. Is there any reason to have the swagger endpoint available open wide rather than on an internal network?
Not particularly, but I assume it will run into the same issue as /metrics, implementing it isnt straight forward enough to bother (at least at the moment)
I know this is not what makes you happy 😄 but in that case, why not just bring up another internal endpoint for /swagger?
Not particularly, but I assume it will run into the same issue as
/metrics, implementing it isn't straight forward enough to bother (at least at the moment)
Isn't an internal 'metrics' already implemented, could swagger be implemented in the same way, or is it more involved.
Out of interest, are these endpoints exposed for tailscale?
Correct me if I'm wrong, but wouldn't it be easiest to just deny access (or blackhole) requests to these routes in the reverse proxy? Might be something worth documenting.
Correct me if I'm wrong, but wouldn't it be easiest to just deny access (or blackhole) requests to these routes in the reverse proxy? Might be something worth documenting.
Yep. These days anything going outside an internal network (really anything going inside an internal network as well) should be gated behind a reverse proxy. Caddy could IP whitelist those endpoints easily. I think headscale (as a service) has done its due diligence by requiring authentication for the API, anything else is on the person securing it.
I was able to find all the endpoints by grep router.HandleFunc ./app.go and I'm curious what other endpoints can be closed to the public.
I will close this as wontfix, as we dont see the general need. There are ways to lock this down outside of headscale and it is currently out of scope.