README should make it clear that sliding-sync proxy should run behind a reverse proxy
axelsimon opened this issue · 3 comments
Currently, the README offers a snippet of nginx config for those wanting to run sliding-sync proxy on the same FQDN as their base Matrix domain, but it doesn't make explicit in any way that in any case, sliding-sync proxy should run behind a reverse proxy like nginx or Caddy.
More problematic, sentences like "Optionally also set SYNCV3_TLS_CERT=path/to/cert.pem and SYNCV3_TLS_KEY=path/to/key.pem to listen on HTTPS instead of HTTP" can let users think that it's ok to run sliding-sync proxy in plain HTTP with clients directly connect to it.
The README should be updated to make it clear that sliding-sync proxy should be run behind a reverse proxy, and ideally provide the configuration for how to do so for nginx and Caddy.
It will probably make sense to also make clearer the two cases described in the readme: running sliding-sync proxy on its own, separate FQDN (cue reverse proxy instructions) and running sliding-sync proxy on the same FQDN as the Matrix base domain (cue reverse proxy instructions).
It's not really our place to say how a server admin should run their proxy.
Whilst I would agree the "typical" configurations would be A) behind a reverse proxy in HTTP mode, B) internet-facing in HTTPS mode, all 4 permutations are valid depending on your use case. You may want to keep using HTTPS inside your DC for security reasons (so C) behind a reverse proxy in HTTPS mode) or you may already be on a custom trusted secure network / testing for evaluation purposes (so D) intranet-facing in HTTP mode).
It's also not at all clear why we would have nginx and Caddy instructions but not Apache, HAProxy, traefik, or countless others. I'd preferably have no reverse proxy instructions at all, as we do not test the snippets we provide so they risk bitrotting, but there is value in having one clear-ish example which can be tweaked depending on your reverse proxy of choice.
This is just unfortunately the cost to running your own servers: you need to know this and cannot expect every piece of server software you run to have your specific requirements exactly met. If we wanted to lower the barrier here, we should be owning more of the networking stack e.g provide a helm chart with an Ingress we know about so can configure correctly for the user.
I don't see anything actionable here, though I am open to PRs which make the documentation clearer for server admins, provided A) it doesn't make the README a choose-your-own-adventure game of if apache then elif nginx then ... as that obfuscates things, B) doesn't rule out valid use cases which the proxy supports, C) isn't a pain to maintain.
How about adding a short paragraph akin to what Synapse's README has? That seems quite clear in intention without obfuscating things and makes sense (to me) since sliding-sync is effectively a HS extension.
I think i understand your position @kegsay, but i respectfully disagree.
It absolutely is the foundation's place to recommend good practices for running (what is now intended to be) a fundamental part of the Matrix stack. As @dkasak pointed out, the synapse README has a section on security, on reverse-proxying, and gives advice on how to run Synapse. (And that's not even a Matrix Foundation project anymore.)
The fact that following the instructions in the README lead to a non-functional, HTTP listening service is a problem.
If we wanted to lower the barrier here, we should be owning more of the networking stack e.g provide a helm chart with an Ingress we know about so can configure correctly for the user.
I'm really not sure how you are reaching the conclusion that providing a helm chart would be the way to lower the barrier. A helm chart would, in all likelihood, be a separate project (and would mean we now require or at least recommend people to be using Kubernetes to deploy, which is not really lowering the barrier for many people).
A basic way of lowering the barrier is to simply provide clearer instructions as i was describing for the two cases of "same FQDN" and "different FQDN" and providing nginx instructions for each case is some actionable. The README already provides some nginx config anyway.
If we wanted to do one better, we could (and probably should) cover the 4 cases A, B, C and D you mention.