Synapse: Ability to disable End-To-End Encryption

[jkms]

Description:
I would like the ability to disable end-to-end encryption in my self hosted Synapse instance. I have a legal requirement to provide audit-able chat logs, which is obviously impossible if there's nothing preventing my end-users from encrypting any room they create.

I originally created an issue for riot-web here, thinking this was an entirely client-side feature. But I suspect there may be a client-side component to fully implementing this feature.

[Half-Shot]

This sounds like the inverse of #4367.

Is this server likely to federate, or connect to servers outside the control of this one. You cannot prevent users from joining rooms where others on may enable e2e, but a feature to disable it via a flag on your own server should be possible. You mentioned "my end-users from encrypting any room they create", so I assume this isn't a federating server?

I don't know where a feature like this sits with the maintainers, however.

[jkms]

Federation is currently enabled, and I would like to keep it. I'm not concerned with users using encryption, I just need to be able to provide logs of communication on my server - if my users join encrypted rooms on other synapse instances, that's fine with me.

[ara4n]

for an unfederated homeserver you could cheat and set the default power levels for rooms created on the server to require impossible power to set m.room.encryption events.

This means adding a line around https://github.com/matrix-org/synapse/blob/master/synapse/handlers/room.py#L679

to say that the power level required to set m.room.encryption is 101 or something.

[jkms]

@ara4n That's an interesting solution. Why isn't that an option for federated homeservers?

[ara4n]

because it only impacts rooms created on your server. if you’re federated, people can create rooms elsewhere, and you can’t control whether they configure them or not to allow crypto.

[jkms]

@ara4n I believe that's an acceptable solution. My legal requirement is to provide logs on my server. Am I correct in understanding that:

• This would not prevent my users from creating/joining encrypted rooms on other homeservers
• This would prevent all users (federated and local) from creating encrypted rooms on my homeserver?

if that's the case, I believe that's acceptable.

[t3chguy]

This would not prevent my users from creating/joining encrypted rooms on other homeservers
This would prevent all users (federated and local) from creating encrypted rooms on my homeserver?

Rooms don't work like this, as soon as one of your users joins a federated room that room is as much on your server as it is on the other servers in the room, e.g Matrix HQ is shared between 505 (at time of writing) servers: https://view.matrix.org/room/!QtykxKocfZaZOUrTwp:matrix.org/servers

[jkms]

Thanks @t3chguy, that makes sense.

I'm still curious, and I'd like to do some testing with @ara4n's solution.

Editing /usr/lib/python2.7/dist-packages/synapse/handlers/room.py, what exactly am I adding? I've tried:

• m.room.encryption: 101,
• EventTypes.Encryption: 101,
• EventTypes.m.room.encryption: 101,

but none of those prevent me from encrypting rooms... hint please :) ?

[t3chguy]

That change prevents rooms which were created on your server from getting encrypted (by any server)

[t3chguy]

(only applies to new rooms and after a server restart are some hints)

[jkms]

I restarted Synapse after all of my changes, and only tested in new rooms - no dice. My

My /usr/lib/python2.7/dist-packages/synapse/handlers/room.py looks like this, at present:

666         pl_content = initial_state.pop((EventTypes.PowerLevels, ''), None)
667         if pl_content is not None:
668             yield send(
669                 etype=EventTypes.PowerLevels,
670                 content=pl_content,
671             )
672         else:
673             power_level_content = {
674                 "users": {
675                     creator_id: 100,
676                 },
677                 "users_default": 0,
678                 "events": {
679                     EventTypes.Name: 50,
680                     EventTypes.PowerLevels: 100,
681                     EventTypes.RoomHistoryVisibility: 100,
682                     EventTypes.CanonicalAlias: 50,
683                     EventTypes.RoomAvatar: 50,
684                     m.room.encryption: 101,
685                     EventTypes.Encryption: 101,
686                     EventTypes.m.room.encryption: 101,
687
688                 },
689                 "events_default": 0,
690                 "state_default": 50,
691                 "ban": 50,
692                 "kick": 50,
693                 "redact": 50,
694                 "invite": 0,
695             }

[t3chguy]

That doesn't look like valid python so something suggests you're not actually running the file, it should be "m.room.encryption" if anything. There is no EventTypes constant for Encryption so the other two lines would also cause exceptions.

[jkms]

Quotes! success!

I'll just leave this here for any fellow travelers:

667         if pl_content is not None:
668             yield send(
669                 etype=EventTypes.PowerLevels,
670                 content=pl_content,
671             )
672         else:
673             power_level_content = {
674                 "users": {
675                     creator_id: 100,
676                 },
677                 "users_default": 0,
678                 "events": {
679                     EventTypes.Name: 50,
680                     EventTypes.PowerLevels: 100,
681                     EventTypes.RoomHistoryVisibility: 100,
682                     EventTypes.CanonicalAlias: 50,
683                     EventTypes.RoomAvatar: 50,
684                     "m.room.encryption": 101,
685                 },
686                 "events_default": 0,
687                 "state_default": 50,
688                 "ban": 50,
689                 "kick": 50,
690                 "redact": 50,
691                 "invite": 0,
692             }

Time to do some testing and see if this satisfies the lawyers :P

Thanks for your help!

[turt2live]

@neilisfragile I don't think this is fixed. It would actually be nice to have this be a config option.

[menturion]

+1
The current key and device handling is too complex for common (non-techie) users. Maybe, the keys could be encrypted solely by server side KEKs that are not encrypted by the user's passphrase(?). This would be ...
-- easier for the users,
-- safer than disabling the encryption completely and
-- would meet legal requirements because the messages could be decrypted if required by law.

[D3-jwatts]

@jkms: I used your suggestion on my own server and it worked perfectly to prevent new rooms w/ encryption! Unfortunately in the latest versions of Riot this prevents direct-messages from being created as there is no user-visible option to disable encryption.

To work around this for now, I've added the following to rooms.py:

            ratelimit=False,
            content=creator_join_profile,
        )

+       # Strip RoomEncryption events
+       pl_content = initial_state.pop((EventTypes.RoomEncryption, ""), None)
+
        # We treat the power levels override specially as this needs to be one
        # of the first events that get sent into a room.
        pl_content = initial_state.pop((EventTypes.PowerLevels, ""), None)
        if pl_content is not None:
            await send(etype=EventTypes.PowerLevels, content=pl_content)

[gmiller01]

@jkms: I used your suggestion on my own server and it worked perfectly to prevent new rooms w/ encryption! Unfortunately in the latest versions of Riot this prevents direct-messages from being created as there is no user-visible option to disable encryption.

To work around this for now, I've added the following to rooms.py:

            ratelimit=False,
            content=creator_join_profile,
        )

+       # Strip RoomEncryption events
+       pl_content = initial_state.pop((EventTypes.RoomEncryption, ""), None)
+
        # We treat the power levels override specially as this needs to be one
        # of the first events that get sent into a room.
        pl_content = initial_state.pop((EventTypes.PowerLevels, ""), None)
        if pl_content is not None:
            await send(etype=EventTypes.PowerLevels, content=pl_content)

Thank you,

You save my day :-)

[chaosgrid]

+1
The current key and device handling is too complex for common (non-techie) users. Maybe, the keys could be encrypted solely by server side KEKs that are not encrypted by the user's passphrase(?). This would be ...
-- easier for the users,
-- safer than disabling the encryption completely and
-- would meet legal requirements because the messages could be decrypted if required by law.

I too would like to show support for such a feature. Or, give a server setting option where everything is simply encrypted with the user-login password.
At the very least, please re-open this issue and make it a config option to let server-admins completely disable encryption.

For our org, it has shown that current implementation of end-to-end encryption is a net-negative and a support nightmare. Not only is the UX still relatively bad, it also still fails on current Element clients while encryption is on by default for direct messages which I find outrageous. Just right now, I wanted to do a simple cross-signing of a new session and I get a message saying "Failed to import keys" (different from when I would enter a bad key phrase) - no hint as to what is going wrong. This frustrates even me, and I have a computer science background, so for the average user, there is no way this feature is usable at the moment on a larger scale.

/EDIT:

Sorry for the redundancy, I just found the better issue for this topic and I want to redirect others to it: https://github.com/matrix-org/synapse/issues/4401

[cmuller]

@jkms: I used your suggestion on my own server and it worked perfectly to prevent new rooms w/ encryption! Unfortunately in the latest versions of Riot this prevents direct-messages from being created as there is no user-visible option to disable encryption.

To work around this for now, I've added the following to rooms.py:

            ratelimit=False,
            content=creator_join_profile,
        )

+       # Strip RoomEncryption events
+       pl_content = initial_state.pop((EventTypes.RoomEncryption, ""), None)
+
        # We treat the power levels override specially as this needs to be one
        # of the first events that get sent into a room.
        pl_content = initial_state.pop((EventTypes.PowerLevels, ""), None)
        if pl_content is not None:
            await send(etype=EventTypes.PowerLevels, content=pl_content)

wow. thank you so much! please provide an option for this!! I am using the Synapse
Third party event rules mechanism not only to prevent users from creating non-direct
conversation rooms but also in direct conversations to prevent them for being encrypted
(see function check_event_allowed in this gist:
https://gist.github.com/cmuller/518ae8c49c76fb40457ec3065c048b5f#forbid-room-creation )

it worked perfectly well using web-based riot but when users were setting up encryption,
e.g., using riot-desktop or Element newer versions, then they were not able to create direct
conversations anymore! your patch made it possible again: thank you so much :-)

It would be really nice to have a configuration so that "local" rooms are required
to be unencrypted _and_ this pop of RoomEncryption events would then be automatic!