Nginx reverse proxy config should explicitly set 'proxy_set_header Host localhost'

[JedMeister]

As per #380 (but for Nginx), the Nginx reverse proxy config snippet should explicitly note that proxy_set_header Host localhost is (or at least may be) required.

Whilst $host may work in some cases, it won't work in all (see Nginx docs on $host).

I was pulling my hair out until I came across this blog. As suggested adding <insecureSkipHostcheck>true</insecureSkipHostcheck> (within the <gui .. > </gui> section of the Syncthing config.xml) worked around it but it felt a bit dirty...

Then I saw this: syncthing/syncthing#3573 (comment)

Problem solved!

[AudriusButkevicius]

I think mentioning that you need to set insecureSkipHostCheck in syncthing makes more sense. We should also mention the security implications of that.

[AudriusButkevicius]

As a minimum this will start bitching about setting up auth. I guess if that is handled by reverse proxy, then setting the host header would be correct.

[calmh]

IMHO, we should not recommend this setting. Syncthing has security features that depend on knowing where a request is coming from and this defeats that.

[JedMeister]

@AudriusButkevicius

I think mentioning that you need to set insecureSkipHostCheck in syncthing makes more sense.

Ok thanks for the feedback. I really appreciate it.

As a minimum this will start bitching about setting up auth.

FWIW, the Syncthing auth appears to work fine behind a reverse proxy (with insecureSkipHostCheck set to true).

@calmh - Ok thanks for that.

So for clarity, would it be correct to say a reverse proxy in front of Syncthing is generally not recommended then?!

And if a reverse proxy is it is needed, setting insecureSkipHostCheck to true is the preferred way to work around the host check error?

[JedMeister]

Pondering this further, I guess the other alternative, is to not have Syncthing itself bound to localhost. That sort of defeats the point of having it behind a reverse proxy though doesn't it?

[AudriusButkevicius]

I think we should explain that you need to set skipHostCheck and explain the security implications.

[JedMeister]

I think we should explain that you need to set skipHostCheck and explain the security implications.

Ok great, thanks @AudriusButkevicius . And what are the security implications? Are there any beyond the security implications of allowing global connection to the Syncthing web UI directly? What am I missing?

FWIW, the problem I'm trying to solve is having global TLS certs for all services on a server. Currently TLS certs are locked down so they're only readable by root. That works fine with any service which starts as root, then downgrades (e.g. Stunnel, Nginx, etc), but not so good in the case of Syncthing. Obviously, I could allow Syncthing to read the certs, but I'm not super keen to loosen the current cert access restrictions.