Rolling a homeserver's database back via backup could cause duplicate OTKs and hence UISIs

element-hq / element-meta

Shared/meta documentation and project artefacts for Element clients

75 stars 12 forks source link

Rolling a homeserver's database back via backup could cause duplicate OTKs and hence UISIs #2155

Open richvdh opened 1 year ago

richvdh commented 1 year ago

Alice messages Bob, claiming a OTK.
Bob's server suffers a meltdown. Bob restores his database from backup.
Carol messages Bob, claiming a OTK. Bob's server re-issues the OTK already given to Alice.
Bob cannot decrypt Carol.

This is somewhat related to https://github.com/vector-im/element-web/issues/3309, in that both are fundamentally about OTKs getting out of sync between client and server.

kegsay commented 9 months ago

This will happen 100% of the time in cases where the server is rolled back and someone has claimed a OTK during the bad new deployment.

richvdh commented 9 months ago

A fix to https://github.com/element-hq/element-meta/issues/1992 would also solve this.

richvdh commented 5 months ago

@uhoreg proposes an interesting mitigation measure: don't back up the OTKs table

uhoreg commented 5 months ago

pg_dump has an option, --exclude-table-data=..., to exclude the data from certain tables, but still back up the table definition

richvdh commented 1 week ago

pg_dump has an option, --exclude-table-data=..., to exclude the data from certain tables, but still back up the table definition

This idea seems good. It will mean that we fall back to fallback keys after the rollback, but that's fine. (Fallback keys are in a separate table to OTKs)

We could also document that you could TRUNCATE TABLE on the OTKs table after restore.