Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Olm sessions can get out of sync #2330

Closed
richvdh opened this issue Sep 22, 2016 · 7 comments
Closed

Olm sessions can get out of sync #2330

richvdh opened this issue Sep 22, 2016 · 7 comments
Labels
A-E2EE P2 S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect

Comments

@richvdh
Copy link
Member

richvdh commented Sep 22, 2016

Under certain circumstances (in particular, when Alice uses one of Bob's one-time keys which has since expired), it's possible for Olm session setup to fail. Worse, there is then no backchannel, so Alice may go on sending pre-key messages over the broken session forever.

@richvdh
Copy link
Member Author

richvdh commented Sep 22, 2016

We probably want a way to expire old sessions anyway, so will need to consider these together.

@richvdh richvdh added the A-E2EE label Sep 22, 2016
@richvdh
Copy link
Member Author

richvdh commented Sep 22, 2016

I'm also seeing established Olm sessions being out of sync (the symptoms being that both ends can send a message using the session, but neither can decrypt). The Olm protocol/algorithm doesn't make it easy to figure out why that is happening, but obviously it can't be just due to expired one-time keys. Possibly #2325 could be a factor. Either way, we're probably going to need to figure out a way to expire old olm sessions.

@richvdh
Copy link
Member Author

richvdh commented Apr 25, 2017

I'm coming to the conclusion that the most effective way to do this will be for senders just to use the Olm session that they most recently received a message on. (This is also the approach used by Signal's Sesame algorithm: https://whispersystems.org/docs/specifications/sesame/#receiving-messages.)

The concern with this approach is that it could weaken security by allowing an attacker to initiate a new Olm session which he controls. For instance, if Eve compromises Bob's device keys, she can send a new message to Alice which will appear to come from Bob; and Alice will then use that session to send new messages, thinking she is sending them to Bob. On the other hand, Eve can do that now - she just might have to try a couple of times to get a session with a lower ID than the existing one. (The current algorithm is for Alice to use the session with the lowest ID, where the ID is defined as a SHA-256 of the three public keys I(A), I(B), and E(B)).

@richvdh
Copy link
Member Author

richvdh commented Apr 25, 2017

(doing the above would also fix #2783)

@uhoreg
Copy link
Member

uhoreg commented Nov 23, 2018

This should be addressed by matrix-org/matrix-js-sdk#780, though it won't fully be fixed until the Android and iOS SDKs get the same fix.

@kittykat
Copy link
Contributor

@richvdh @uhoreg do you know if the fix has made it to Android and iOS, and if this issue can now be closed?

@uhoreg
Copy link
Member

uhoreg commented Nov 26, 2021

The Element Android and matrix-ios-sdk contain references to the keyword "unwedging", so I would assume that they now do this.

@uhoreg uhoreg closed this as completed Nov 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-E2EE P2 S-Major Severely degrades major functionality or product features, with no satisfactory workaround T-Defect
Projects
None yet
Development

No branches or pull requests

4 participants