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

Ability to disable End-To-End Encryption #4367

Closed
jkms opened this issue Jan 8, 2019 · 29 comments
Closed

Ability to disable End-To-End Encryption #4367

jkms opened this issue Jan 8, 2019 · 29 comments

Comments

@jkms
Copy link

jkms commented Jan 8, 2019

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
Copy link
Collaborator

Half-Shot commented Jan 8, 2019

This sounds like the inverse of element-hq/element-web#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
Copy link
Author

jkms commented Jan 8, 2019

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
Copy link
Member

ara4n commented Jan 8, 2019

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
Copy link
Author

jkms commented Jan 8, 2019

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

@ara4n
Copy link
Member

ara4n commented Jan 8, 2019

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
Copy link
Author

jkms commented Jan 8, 2019

@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
Copy link
Member

t3chguy commented Jan 9, 2019

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
Copy link
Author

jkms commented Jan 9, 2019

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
Copy link
Member

t3chguy commented Jan 9, 2019

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

@t3chguy
Copy link
Member

t3chguy commented Jan 9, 2019

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

@jkms
Copy link
Author

jkms commented Jan 9, 2019

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
Copy link
Member

t3chguy commented Jan 9, 2019

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
Copy link
Author

jkms commented Jan 9, 2019

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
Copy link
Member

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

@menturion
Copy link

menturion commented Feb 23, 2019

+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
Copy link

@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
Copy link

@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
Copy link

chaosgrid commented Jul 22, 2020

+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: #4401

@cmuller
Copy link

cmuller commented Aug 21, 2020

@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!

@easaw
Copy link

easaw commented Mar 20, 2021

@jkms @D3-jwatts sorry to ask, but can I confirm where "rooms.py" is?

TL;DR If I need to create it where should it go?

I don't have a synapse folder in /usr/lib/python2.7/dist-packages/ (or other python folders since that was first mentioned in 2019)

I've done a grep search and can't find rooms.py or room.py

I'm not sure if it should exist or if I need to create it and reference it elsewhere?

Thank you.

@t3chguy
Copy link
Member

t3chguy commented Mar 20, 2021

Synapse is python 3 only now, so it'll be under the dist-packages directory of whatever python 3 installation you have.

@easaw
Copy link

easaw commented Mar 20, 2021

Thanks @t3chguy, sorry to be a pain, I've been using CLI for a few years but this just makes me feel like a n00b (I've even used SFTP to check for the Synapse directory).

I have 3, 3.8 and 3.9 (under /usr/lib if that's correct?)

I looked under

/usr/lib/python3/dist-packages
/usr/lib/python3.8/dist-packages
/lib/python3/dist-packages

for Synapse and synapse, nothing found :(

python3.9 has no dist-packages dir.
I'm on Ubuntu 20.04 if that helps.

Thank you for your help.

@t3chguy
Copy link
Member

t3chguy commented Mar 20, 2021

It depends on how you installed Synapse - I suggest going to an actual support room rather than a closed issue ticket.

http://matrix.to/#/#synapse:matrix.org

@gmiller01
Copy link

gmiller01 commented Mar 20, 2021

Try to search here:
/opt/venvs/matrix-synapse/lib/python3.x/site-packages/synapse/handlers/room.py

@digitalentity
Copy link

Another solution which I'll just leave here for people who struggle like me https://github.com/digitalentity/matrix_encryption_disabler

@babolivier
Copy link
Contributor

@digitalentity please do not spam issues.

@digitalentity
Copy link

Noted. Merely trying to help users mitigate a 3 year old feature request element-hq/element-web#4401.

@AriBerisha
Copy link

Simpler method would be to return json data, however it only turns off default encryption for rooms
On nginx just paste this
location /.well-known/matrix/client { return 200 '{"im.vector.riot.e2ee": {"default": false}}'; default_type application/json; add_header Access-Control-Allow-Origin *; }

@SimpleUniversalModOrganizer

Since this is the first Issue that shows up, and to stop people from spending 30min going down the github rabbithole, here is a simple solution: https://github.com/digitalentity/matrix_encryption_disabler

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests