Live data from Hacker News

Tailscale Authentication for Nginx

tailscale.com

11–20 of 45 posts

Re: Tailscale Authentication for Nginx

#13
post #3
post #2

This is pretty cool, but does potentially open any of these services not just to the browser but to any malware running on your clients. Probably not a huge deal in most cases but something to keep in mind.

Author of the post here. Realistically this is about as dangerous as what you have already with anything behind an SSH server. If you really need to be sure an actual human is making a request, use a yubikey 2fa challenge. I'll update the post to include this on Monday (I'm off for the rest of the week).

Are there any additional issues with CSRF? I assume if websites are already protected against CSRF then there are no problems and if they don't have CSRF protection then they already have a problem they need to fix.

Re: Tailscale Authentication for Nginx

#15
post #4

Neat to see this up here! When I saw xena's initial post about Grafana I saw an opportunity to make it work with an existing, well known, basically bullet proof proxy (nginx). Xena took my sketchy POC and made it great :) One interesting enhancement, which is probably not within scope of this tool, would be a way to logically AND a bunch of these auth tools together. With that you could use this tool without changes…

Yeah I've been thinking about that too. Something I've been wondering about is tying things to the ACL file through something like "capabilities"[1], but this would probably require a fair bit of per-service hacking. I think it'd be worth it, but it would be a lot of work. The main problem here is that Tailscale ACLs only really have "can connect to port" as the main capability they provide. I think I could end up telling the nginx-auth proxy if the person is a network admin or not (I'm not sure if that capability reliably shows up in whois responses, will need to check), that may be a starting point but it certainly won't scale.

[1]: https://github.com/tailscale/tailscale/issues/4217

Re: Tailscale Authentication for Nginx

#16
post #3

Earlier quoted context omitted.

Author of the post here. Realistically this is about as dangerous as what you have already with anything behind an SSH server. If you really need to be sure an actual human is making a request, use a yubikey 2fa challenge. I'll update the post to include this on Monday (I'm off for the rest of the week).

Are there any additional issues with CSRF? I assume if websites are already protected against CSRF then there are no problems and if they don't have CSRF protection then they already have a problem they need to fix.

I have no idea to be honest. I'd assume CSRF protection is kind of a mandatory part of the internet at this point.

Re: Tailscale Authentication for Nginx

#17

I've been meaning to try something similar for Kubernetes/OpenShift-- you can set up authentication (technically an identity provider) through a configurable HTTP header. My idea was having the reverse proxy only listen on the tailscale IP, but this is even cooler.

If you get this working, please do email me at xe at tailscale dot com. I'd love to document this so that other people can benefit from it.

Re: Tailscale Authentication for Nginx

#19
post #15
post #4

Neat to see this up here! When I saw xena's initial post about Grafana I saw an opportunity to make it work with an existing, well known, basically bullet proof proxy (nginx). Xena took my sketchy POC and made it great :) One interesting enhancement, which is probably not within scope of this tool, would be a way to logically AND a bunch of these auth tools together. With that you could use this tool without changes…

Yeah I've been thinking about that too. Something I've been wondering about is tying things to the ACL file through something like "capabilities"[1], but this would probably require a fair bit of per-service hacking. I think it'd be worth it, but it would be a lot of work. The main problem here is that Tailscale ACLs only really have "can connect to port" as the main capability they provide. I think I could end up te…

That's an interesting issue, thanks for linking. I could see something like this working well:

  location /auth {
    ...
    proxy_set_header X-Required-Caps $required_caps;
    ...
  }

  location /grafana {   
    ...
    set $required_caps "grafana.com/read,grafana.com/write"
    auth_request_set $auth_caps $upstream_http_tailscale_caps;
    proxy_set_header X-Webauth-Caps $auth_caps;
    ...
  }
I.e. pass the caps through an nginx variable up to the `/auth` location, then out to `nginx-auth`, then nginx-auth passes all(?) of the user's caps to the upstream.

Re: Tailscale Authentication for Nginx

#20
post #16

Earlier quoted context omitted.

Are there any additional issues with CSRF? I assume if websites are already protected against CSRF then there are no problems and if they don't have CSRF protection then they already have a problem they need to fix.

I have no idea to be honest. I'd assume CSRF protection is kind of a mandatory part of the internet at this point.

I think if you are checking the host header on the server there is no problem. But I think if you are not checking the host header then there are some cute DNS rebinding attacks that will let an evil website perform arbitrary actions on behalf of a user if they are tricked into navigating onto the evil website. i've seen this same attack on sites hosted locally where authentication is assumed because only the localhost can connect to the site. DNS rebinding breaks this assumption. i think there is a similar thing going on here.

the good thing is a lot of stuff kind of implicitly checks the host header. like if you are using vhosting (without a default) then you have an implicit host header check even if you didn't set it up explicitly for security.

EDIT: and of course if you are using HTTPS then it should not be an issue because the server will not be able to serve a certificate that matches the hostname.

Post reply on HN