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

federation: refresh devices_list for users more frequently #5433

Open
cyphar opened this issue Jun 12, 2019 · 1 comment
Open

federation: refresh devices_list for users more frequently #5433

cyphar opened this issue Jun 12, 2019 · 1 comment
Labels
A-Device-List-Tracking Telling clients about other devices. Often related to E2EE. A-Federation O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Major Major functionality / product severely impaired, no satisfactory workaround. T-Enhancement New features, changes in functionality, improvements in performance, or user-facing enhancements. z-feature (Deprecated Label) z-p3 (Deprecated Label) z-uisi (Deprecated Label)

Comments

@cyphar
Copy link

cyphar commented Jun 12, 2019

Description:

Let's take two homeservers A.com and B.com. You've set up A.com and B.com and they are both federating with one another freely.

At the moment if you (possibly accidentally) nuke your already-federated A.com server and want to rebuild it using the same server_name things work mostly fine (B.com seems to accept the new signing key of your server without much issue, and federated events between A.com and B.com work properly).

However, one issue that occurs is that the cached device list of A.com's users on B.com will persist (assuming that you've kept the same usernames on the new installation). Not only that, but because the database has been completely nuked, A.com won't know that it needs to send m.device_list_update EDUs to B.com. This results in E2EE over federation being basically broken permanently because users on B.com won't negotiate new Megolm session keys (because they don't see the new A.com devices and instead only see the ghost ones.

Would it be acceptable to make synapse automatically do a hard refresh of the devices list of the users on a federated server if the signing key of the homeserver changes? This could be done lazily (effectively just remove the cached information about devices, and when a user requests it then we fetch it over federation). Is there any attack that I'm missing which much result if we make this a default feature?

Workaround

As a quick hack, it is possible to fix this using the manhole in synapse -- by sending a m.device_list_update EDU to B.com which has a broken value of prev_id. According to the spec this causes B.com to reset its cached device list:

If a server receives an EDU which refers to a prev_id it does not recognise, it must resynchronise its list by calling the /user/keys/query API and resume the process.

Manhole Script -- USE AT YOUR OWN RISK
broken_server = "B.com"
user_id = "@cyphar:A.com"

fs = hs.get_federation_sender()
k = fs._per_destination_queues[broken_server]._store.get_devices_with_keys_by_user(user_id)
content = {"user_id": user_id, "stream_id": k.result[0]+2, "prev_id": [k.result[0]+1], **k.result[1][0]}
fs.build_and_send_edu(broken_server, "m.device_list_update", content)
@cyphar
Copy link
Author

cyphar commented Jun 13, 2019

From #5095, one of the proposed solutions of re-syncing the devices list if we see an unknown device event would solve this problem too (though at the risk of nuking the device list cache more frequently).

@cyphar cyphar changed the title federation: refresh devices_list for users if their homeserver signing key changes federation: refresh devices_list for users more frequently Jul 1, 2019
@richvdh richvdh added z-feature (Deprecated Label) z-p3 (Deprecated Label) z-uisi (Deprecated Label) labels Feb 26, 2020
@reivilibre reivilibre added A-Federation A-Device-List-Tracking Telling clients about other devices. Often related to E2EE. S-Major Major functionality / product severely impaired, no satisfactory workaround. T-Enhancement New features, changes in functionality, improvements in performance, or user-facing enhancements. O-Uncommon Most users are unlikely to come across this or unexpected workflow labels May 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A-Device-List-Tracking Telling clients about other devices. Often related to E2EE. A-Federation O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Major Major functionality / product severely impaired, no satisfactory workaround. T-Enhancement New features, changes in functionality, improvements in performance, or user-facing enhancements. z-feature (Deprecated Label) z-p3 (Deprecated Label) z-uisi (Deprecated Label)
Projects
None yet
Development

No branches or pull requests

3 participants