search

kamax-matrix / mxisd

Federated Matrix Identity Server
GNU Affero General Public License v3.0
220 stars 112 forks source link

Limit remote 3pid lookups #52

Closed psscud closed 6 years ago

psscud commented 6 years ago

First I'd like to say thank you for your work on this project. The documentation for Sydent is very poor and without this project I definitely wouldn't have gotten a Matrix ID server working nearly as quickly.

This is related to issue #51

There needs to be a configurable limit on the number of attempts/rate of attempts that mxisd sends for remote 3pid lookups. Currently it sends 3PID lookups to matrix.org/vector.im every minute. The real problem is when there is no mapping for the 3PID. It will continue to spam lookups apparently indefinitely?

As an example, my journalctl output | grep https://matrix.org looks like:

Feb 20 22:18:16 ip-10-0-0-43 mxisd[14305]: .869  INFO [onPool-worker-1] k.m.l.p.RemoteIdentityServerFetcher : Looking up email 3PID testsynapse5@pokemail.net using https://matrix.org
Feb 20 22:18:17 ip-10-0-0-43 mxisd[14305]: .559  INFO [onPool-worker-1] k.m.l.p.RemoteIdentityServerFetcher : Empty 3PID mapping from https://matrix.org
Feb 20 22:19:17 ip-10-0-0-43 mxisd[14305]: .820  INFO [onPool-worker-0] k.m.l.p.RemoteIdentityServerFetcher : Looking up email 3PID testsynapse5@pokemail.net using https://matrix.org
Feb 20 22:19:18 ip-10-0-0-43 mxisd[14305]: .770  INFO [onPool-worker-0] k.m.l.p.RemoteIdentityServerFetcher : Empty 3PID mapping from https://matrix.org
Feb 20 22:20:18 ip-10-0-0-43 mxisd[14305]: .686  INFO [onPool-worker-1] k.m.l.p.RemoteIdentityServerFetcher : Looking up email 3PID testsynapse5@pokemail.net using https://matrix.org
Feb 20 22:20:19 ip-10-0-0-43 mxisd[14305]: .388  INFO [onPool-worker-1] k.m.l.p.RemoteIdentityServerFetcher : Empty 3PID mapping from https://matrix.org
Feb 20 22:21:17 ip-10-0-0-43 mxisd[14305]: .387  INFO [onPool-worker-0] k.m.l.p.RemoteIdentityServerFetcher : Looking up email 3PID testsynapse5@pokemail.net using https://matrix.org
Feb 20 22:21:18 ip-10-0-0-43 mxisd[14305]: .320  INFO [onPool-worker-0] k.m.l.p.RemoteIdentityServerFetcher : Empty 3PID mapping from https://matrix.org
Feb 20 22:22:17 ip-10-0-0-43 mxisd[14305]: .362  INFO [onPool-worker-1] k.m.l.p.RemoteIdentityServerFetcher : Looking up email 3PID testsynapse5@pokemail.net using https://matrix.org
Feb 20 22:22:18 ip-10-0-0-43 mxisd[14305]: .378  INFO [onPool-worker-1] k.m.l.p.RemoteIdentityServerFetcher : Empty 3PID mapping from https://matrix.org
Feb 20 22:23:16 ip-10-0-0-43 mxisd[14305]: .851  INFO [onPool-worker-0] k.m.l.p.RemoteIdentityServerFetcher : Looking up email 3PID testsynapse5@pokemail.net using https://matrix.org
Feb 20 22:23:17 ip-10-0-0-43 mxisd[14305]: .768  INFO [onPool-worker-0] k.m.l.p.RemoteIdentityServerFetcher : Empty 3PID mapping from https://matrix.org
Feb 20 22:24:17 ip-10-0-0-43 mxisd[14305]: .372  INFO [onPool-worker-1] k.m.l.p.RemoteIdentityServerFetcher : Looking up email 3PID testsynapse5@pokemail.net using https://matrix.org
Feb 20 22:24:18 ip-10-0-0-43 mxisd[14305]: .310  INFO [onPool-worker-1] k.m.l.p.RemoteIdentityServerFetcher : Empty 3PID mapping from https://matrix.org
Feb 20 22:25:16 ip-10-0-0-43 mxisd[14305]: .772  INFO [onPool-worker-0] k.m.l.p.RemoteIdentityServerFetcher : Looking up email 3PID testsynapse5@pokemail.net using https://matrix.org

I currently work around this problem by running a cron job for a script that periodically cleans out the invite and session database, which looks like this:

#!/bin/bash
# This will clean the mxisd database of all entires
echo 'cron job executing to clean mxisd database'
sudo systemctl stop mxisd
sudo sqlite3 /var/opt/mxisd/mxisd.db <<EOF
DELETE FROM session_3pid;
DELETE FROM invite_3pid;
VACUUM;
EOF
sudo systemctl start mxisd
echo 'database clean completed'

Maybe I have something configured wrong, but I feel like there needs to be a failsafe to keep this from happening. T

Thanks, Pete

maxidorius commented 6 years ago

Hello Pete, thank you for the kind words! I am very happy you found our project useful and managed to not get stuck and scared by sydent.

About those repeated attempts, it is by design and also necessary to be compliant with the Matrix Identity service specification since sessions and invites could be resolved on the matrix.org/vector.im IS, instead of your own. As mxisd uses a federated and recursive lookup mechanism, we need to keep fetching for data for as long as the invitation and/or session is valid.

For 3PID sessions, the spec mandates 24h maximum validity. For invites, they are good indefinitely without a way to cancel one.

Cleaning the database will most leave your HS in a stuck state for those invites at best, and could lead to some disaster at worse (synapse will not be happy in the long run) and therefore I must strongly advise against manually cleaning those tables.

Now, on the matter of actually improving this:

psscud commented 6 years ago

Max,

I did not know this was a specification mandate. Is there a limit on the number of session requests a user can submit? My concern is that this as a potential vector for DoS/DDoS attacks; if you can generate thousands of invalid 3PID invites that never expire and are resubmitted every minute their effect will be cumulative.

I should note that my use case for Synapse/MXISD is as a test for a corporate environment with no federation with Matrix.org, so I'd actually prefer to eliminate remote 3PID lookups altogether. I discovered this issue after I tested out 3PID email registration/invite lookups, however I since read your excellent instructions for directory user lookup ( https://github.com/kamax-io/mxisd/blob/master/docs/features/directory-users.md ) which has made email registration much less of an issue.

I'm definitely interested in your https://github.com/kamax-io/mxhsd project.

Thanks for your time, Pete

maxidorius commented 6 years ago

I did not know this was a specification mandate. Is there a limit on the number of session requests a user can submit? My concern is that this as a potential vector for DoS/DDoS attacks; if you can generate thousands of invalid 3PID invites that never expire and are resubmitted every minute their effect will be cumulative.

and

Is there any way to change the lookup rate for the invites from 1 minute? Or is that also a Matrix specification requirement?

Agreed. The whole Identity server ecosystem is a bit in limbo and the current setup is a placeholder until someone comes up with a good path forward, which is something I am trying to do with mxisd and showing real use cases back to the matrix.org peeps.

Also, federation is not part of the official spec, that's something we added and definitely needs further work. Our point of view is that there shouldn't be a central IS like there is one today, but that's another issue that needs to be solved.

There is currently no configurable option for how often the lookups happen but it seems like a sensible thing to allow to be configured and I've created #53 to keep track of it.

I should note that my use case for Synapse/MXISD is as a test for a corporate environment with no federation with Matrix.org, so I'd actually prefer to eliminate remote 3PID lookups altogether.

Because one of the most important directive of mxisd is to remains as compliant as possible with the current Matrix environment, creating an "island" (so to speak) is not something we support as it can actually lead to several issues with synapse and/or Riot, made by the matrix.org devs and expecting to use their own IS service.

The best I can offer you is:

psscud commented 6 years ago

Max,

I totally understand why Matrix servers need to be federated, and why central registration is currently necessary. If the protocol and associated applications can't expand to easily reach the general public then they will die out as a project. My use case is more of a fringe use.

Thanks, Pete