Reverse proxy configuration for apache

[WTFThatPerson]

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

[JedMeister]

Apparently setting Host as localhost/127.0.0.1 is bad idea. The preferred workaround when behind a reverse proxy is to set <insecureSkipHostcheck>true</insecureSkipHostcheck> (within the <gui .. > </gui> section of the Syncthing config.xml).

See discussion in #401

[WTFThatPerson]

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"?

[JedMeister]

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).

[WTFThatPerson]

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

[AudriusButkevicius]

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.

[WTFThatPerson]

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? :)
At another hand, none use reverse proxy just for nothing, it assumes we have use another proxy clients on device in parallel. And every other program has exatly same problem with DNS binding vulnerability, so we end up with firewalling inside every program which is nonsense, of course. If one setting up reverse proxy, he can use web firewall, say ModSecurity, and simple something like
SecRule REQUEST_HEADERS:Host "!^www.example.com(:[0-9]+)?$" "id:1, phase1 t:none, nolog, deny, status:403"
cures everything with ease, I don't mention about extra security with CRS packet.
And BTW, TLS breaks malicious connection attempt, because it won't decrypt data without certificate.
So, IMHO, You can leave syncthing docs mostly untouched, with one adding, something like "we highly advise against using reverse proxy combined with plain http, but with https only" with explaining of security breaches

[AudriusButkevicius]

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.

[calmh]

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:

• Lie to Syncthing by telling it the request is originating from localhost. (i.e., set Host: localhost), or
• Tell Syncthing to not enforce security related to localhost requests (insecureSkipHostCheck=true).

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.