-
-
Notifications
You must be signed in to change notification settings - Fork 678
Sending E2EE messages dendrite -> matrix.org randomly fails to provide keys #2184
Comments
I am seen a similar problem, most likely the same as @bones-was-here I have tested this between my test account on matrix.org and my personal and main account on hispagatos.org. I can read what my matrix.org account writes to me on a 1:1 but when I write from hispagatos.org account on the other side I get a "message could not be decrypted" and sometimes other similar ones on the matrix.org side. This is noticeable specially on some rooms we host between people on diverse matrix servers, they have been complaining that they can't see any of the people's msg's that come from our dendrite server. |
So this could be either:
|
Edit: just updated to 5dd203f and at startup:
|
Wow that's worrying. That sounds like:
|
I think it is encrypting, just with no way for the client to decrypt and no way for the sender to know there was a problem. I reproduced it just now:
|
The growth rate of stream "DendriteOutputKeyChangeEvent" is currently averaging about 125 messages per minute. |
in our case, I had reports of people on small instances getting our keys and eventually been able to read msgs from users on our server like around 9-10 have reported this, but on matrix.org people never can see any of the msg any one on our server post and we have a bunch of people using dendrite daily. |
As mentioned in chat, the spam mentioned in OP looks like this (in element 1.10.4 in firefox or element desktop)
It continues like that at several requests per second whenever the client(s) are open, with the same behaviour in all new sessions. |
0.6.4 E2EE DM update: no change. With fresh sessions element web is sending un-decryptable messages, element android is sending decryptable messages. Same procedure in both: log in, paste in my e2ee key, successfully restore all keys from backup, sessions show as verified in both clients, all e2ee message history is readable. |
0.6.4 is tending to log several of these when trying to send e2ee DM: |
And possibly some leftover issue from the OTK cleanup #2208 |
I changed log level to debug and the homeserver is printing Currently it's the same two users in all the messages, I know both of them and am confident they're not attacking the homeserver :) One is on matrix.org, the other is on a personal homeserver that also runs synapse. |
It seems to be Nheko clients causing the QueryKeyChanges spam, and Nheko spams the server much faster than my Element client does. But the fact that both clients are spamming the server (with sync requests) suggests they expect something that Dendrite isn't providing. |
Is this still the case on 0.7.0 or |
@neilalexander I will ask my users later on our private channel see if they still had it, Myself last week someone from matrix .org told me he can't read me. I do git pull and ./build.sh daily so not sure which version it was, but tonight I will try to log in with my test account on matrix.org and ask my users and report back. thanks |
@neilalexander they say is better but it happens at times, and I just remembed to reply here because I logged into my test account on matrix.org and I just replicated it again today |
There seems to be a pattern to the inability of matrix.org users to decrypt messages sent from Element Web on Dendrite. If I have not started Element Android (eg rebooted phone) recipient gets: If I have started it but it's not currently running (eg phone in sleep) recipient gets: If I keep the phone plugged in with Android dev options set to always keep the screen awake, and I keep Element as the foreground app (just idling at the room list), E2EE works in Element Web. |
I can confirm this issue still with dendrite 0.8.8. I can also confirm that it not only happens with element but also with https://github.com/poljar/weechat-matrix which is based on I will test if https://github.com/matrix-org/dendrite/releases/tag/v0.8.9
solve this issue. Update Nope still an issue. |
I've had unable to decrypt errors with both participants using Android client and connected to "same" Dendrite server. I've just upgraded to latest dendrite via pull request, still can't get the keys. |
Adding some logs for this one on my end since I'm able to confirm that dendrite isn't sending keys to matrix:
|
Just a quick update: It started out failing to send the keys upon the room's creation. I tried to recreate it by leaving the room and creating a new one, however after one room successfully exchanged keys, all subsequent room creations with the same participants successfully exchanged keys. Maybe it has to do with stale keys if there is some time factor to it or maybe a race condition? |
I discussed the issue with a user in the Dendrite chat and was told to run some DB commands that "Instructs Dendrite to re-new the device lists/keys of the given user, so hopefully your client now received a device_list.changed entry for that user and encrypts messages successfully to that user" I ran these commands on my postgres server, which seems to have resolved the issue for now: this seems to have helped with the issue. I am not sure how this could be worked into fixing the main issue, but thought it relevant. |
@S7evinK appears to be working on making an e
@S7evinK appears to be working on an admin endpoint to streamline this procedure without requiring a dendrite server reboot (#2746 ) and messing around in the db. The most recent commits that deal with parsing commit e1bf709 appears to have helped with e2ee as well. If anyone is still showing this problem, please try updating to the latest commit |
With a recent change |
e2ee no longer works at all for me, in rooms where it did previously work, even between 2 users of the same dendrite instance. |
Which commit are you on? We've been hearing the opposite overall from most users, that things have improved dramatically since 0.10.6 and the latest |
0.10.6 currently. It got worse some time around 0.8.x or 0.9.x (rooms that used to work most of the time started breaking, the workaround of having all clients open simultaneously no longer helped) and currently seems broken all the time. Very old messages from when it used to work can still be decrypted. The messages that were sent before the invited user joined are visible now (after the usual clear cache & reload dance) so DM works better in that regard, but those also can't be decrypted if e2ee is enabled. |
Not sure if relevant to /members but on 0.10.6 when joining a DM via an invite, i still hit the incorrect users counting issue #2514 (it showed a total of 0 people but correctly listed 2). Most rooms have correct member counts but our main room member count still shows an extra 12 users compared to synapse (even on the dendrite that originally created the room). |
|
I havn't seen any e2ee failures on 0.10.7 yet :) |
Just had an e2ee failure when another user of the same dendrite instance switched from element web to element android I could not decrypt the messages he sent from Android, and after re-syncing the android client he could no longer decrypt my messages. He's using cross signing whereas I paste in the backup key whenever I log in to a client, so possibly cross signing is flakey. |
He reckons it works (for a while) if he's able to have both clients active at the same time. |
I am having the same issue. I can provide logs if that can help 🙂 |
Having the same issue. |
Background information
go version
: 1.17.6Description
Steps to reproduce
"Recently" I've noticed a new issue where clients will constantly spam the server with key related requests.
I had reliability issues with sending E2EE messages before that, but now element in firefox and element desktop and nheko are constantly making key related requests in an endless loop. I don't know how to open a debug output in android but the CPU load on the phone from running Element is continuous and the network never idles when it's open.
Describe how what happens differs from what you expected.
E2EE should reliably work (and if it can't work there should be an error printed somewhere, not a silent failure that gives the impression the message was sent successfully).
The text was updated successfully, but these errors were encountered: