Skip to content
This repository was archived by the owner on Apr 26, 2024. It is now read-only.
This repository was archived by the owner on Apr 26, 2024. It is now read-only.

Clarify recommended setup #2438

@maxidorius

Description

@maxidorius

EDIT as to provide guidance to new users - Synapse devs official answer #1 and #2

TL;DR

  • CLIENT and FEDERATION ports are DIFFERENT, they do not use the same port.
  • TCP 8448 (Default, can change): Federation, HTTPS, original generated self-signed certificate, directly exposing port TCP 8448 of synapse (NO reverse proxy, NO replace certificate)
  • TCP 443: Clients, HTTPS, regular certificate (e.g. Let's Encrypt), reversed proxy to port TCP 8008 of synapse

The self-signed certificate of synapse SHOULD NOT be replaced and port 8448 should only be used for federation (server traffic) and directly exposed publicly.

For clients connections, a reverse proxy should be reachable publicly with a regular certificate (e.g. Let's Encrypt) on port 443 that goes to the port 8008 of synapse.

This is the last option in the first list below.


The community is currently discussing what is the official recommended setup for synapse in terms of ports and reverse proxying. Here are the three visions:

  1. Use a regular (e.g. LTE) certificate on port 8448 and expose that for clients and servers, replacing the self-signed generated one.
  2. Use a regular certificate on 443 reversed proxy to 8008 and same cert on 8448, replacing the self-signed generated one.
  3. Use a regular certificate on 443 reversed proxy to 8008 and keep the self-signed generated one on 8448

My personal believe is to do go for 3) but it seems many users in the community for for 1) or 2), which I believe is due to misleading documentation for synapse.

Why I think 1) and 2) occurs due to misleading doc:
First mention of 8008 and 8448 is at Configuring synapse, last paragraph which gives the first misleading advise.
It says 8448 has a self-signed certificate which is fine to test with clients but should be replaced in production but also state that it's fine for Federation. So if you want to connect clients to 8448, you should put a proper certificate - yet doesn't instruct to connect clients to it outside of a testing scope.

The next bit comes with Connecting to Synapse from a client which says again that the easiest way to try a synapse install is to connect to 8448 but totally ignores the fact it's a self-signed and will be a problem. So you're made to believe you should have changed the certificate.

Then we come to Using a reverse proxy with Synapse which says it will work nicely with clients as you expose 443 and continues by saying clients and servers don't necessarily need to connect to the same port, says and shows a nginx config of 443->8008 for clients.

Finally, several generic points:

  • Changing the certificate only matters for clients. Servers don't require anything specific.
  • 8448 doesn't work out of the box for clients (due to self-signed) but does for federation
  • 443 to a unencrypted 8xxx port is the typical setup with TLS offloading
  • 8008 is enabled by default in the config. If 1) was intended, why not just keep 8448?
  • if you use 443 for clients, you don't need to give the port when configuring, just put https://example.org - easy for users, easy for admins
  • Reverse proxy 443 to 8448 with self-signed certificate might not work out of the box, so you would go for 8008 (and double TLS/SSL would not make much sense)
  • synapse README never instructs or even recommends to use 8448 for clients in production, only for testing
  • going for 2) means managing two configuration files and two copies of the same certs after each renewal
  • The Server-Server Spec talks about caching results of looking up certificates and signing keys, which could cause downtime depending on homeservers implementation/configuiration?

Could the Matrix devs please clearly state what is the recommended setup?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions