-
Notifications
You must be signed in to change notification settings - Fork 488
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reverse proxy configuration for apache #380
Comments
Apparently setting Host as localhost/127.0.0.1 is bad idea. The preferred workaround when behind a reverse proxy is to set See discussion in #401 |
I'm not sure I understand clearly what do You talking about. As per my understanding, for reverse proxy given, HeaderRequest modifies request header on the way "proxy -> target" only. i.e. inside server. Why do You think InsecureSkipHostcheck turning off host checking globally is "preferrable"? |
I'm just repeating what the devs mentioned on my similar issue #401 (same issue, just with Nginx rather than Apache). E.g. see #401 (comment) and/or #401 (comment) and/or #401 (comment) Or perhaps more clearly (forcefully?): #402 (comment) (on the PR I opened to change the docs). |
Again, I don't understand all that arguments. InsecureSkipHostcheck completely disables host name checking, so how it can better way against HeaderRequest? One can discuss what he likes more: HeaderRequest or InsecureSkipHostcheck, but it's not a reason to give advices at a confident manner |
What if syncthing behaves differently in terms of security when it knows the requests are not coming from local host? Is it then better to lie that the requests are coming from local host? I am not saying syncthing does behave differently, I am just raising a hypothetical question. |
Well, what we ended up, is some kind of IP filtering, so, we talk about firewall functionality, right? But wait a minute, it's all about lightweight syncing program with small resources consumption, isn't it? :) |
Whats wrong with a firewall in every application? Are you suggesting to leave ourselves vulnerable if we don't run behind a proxy? Anyways, if the proxy has mitigation for dns rebinding, then it doesn't matter which you do. |
Look at it this way. Syncthing treats requests differently when bound to localhost and not bound to localhost - at the moment specifically to protect against DNS rebinding, in the future potentially in other ways as well. When running behind a reverse proxy the requests are not coming from localhost, despite how it may seem to localhost-bound Syncthing. They therefore fail the checks. This is clear to everyone involved. You then have two possible solutions:
The effects of the first are unclear, especially in the face of future development. The effects of the second are specified - you're telling Syncthing to not concern itself where the request is coming from, as you're taking care of that yourself. This is the cleaner option. |
That sample configuration
ProxyPass /syncthing/ http://localhost:8384/
<Location /syncthing/>
ProxyPassReverse http://localhost:8384/
Require all granted
isn't enough, 'cos it doesn't prevent from host check error; You should to add
HeaderRequest there, i.e.
ProxyPass /syncthing/ http://localhost:8384/
<Location /syncthing/>
ProxyPassReverse http://localhost:8384/
HeaderRequest set Host 127.0.0.1
Require all granted
The text was updated successfully, but these errors were encountered: