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

Jitsi integration URLs are deterministic #13511

Closed
robertwessen opened this issue Feb 19, 2019 · 3 comments
Closed

Jitsi integration URLs are deterministic #13511

robertwessen opened this issue Feb 19, 2019 · 3 comments

Comments

@robertwessen
Copy link

robertwessen commented Feb 19, 2019

Description:

There still exists a privacy issue in the current Jitsi integration. Any one user can calculate all jitsi URLs for any user/room combo (including video meetings launched from DMs)

I think a feature when launching a new jitsi meeting would be needed to address this best. It would require two different jitsi meeting types when launched from RC:

  1. permanent meeting - a jitsi url which is determined much like the current implementation. the url is deterministic, based on the ID of install and users/channel name. This is useful for long term consistent meetings on a topic, channel or group.

  2. ephemeral meeting - similar to a permanent url, but with a nonce (HMAC of same ID values w/ nonce as key?) to make it unique. New nonce is created every time an ephemeral jitsi meeting is requested. This is best for private meetings which should only last as long as the jitsi session itself and be random enough to give basic privacy properties.

Expected behavior:

Jitsi meetings launched from RC should provide some privacy, at least equivalent to the protections provided within RC.

Actual behavior:

Any one user of RC can calculate the jitsi meeting URL of rooms and DMs (between any two users) as the Jitsi URLs are based on public account/room ID values.

Server Setup Information:

  • Version of Rocket.Chat Server: 0.74.3
  • Operating System: Ubuntu 16.04
  • Deployment Method: docker
  • Number of Running Instances: 1
  • DB Replicaset Oplog: none
  • NodeJS Version: v8.11.4
  • MongoDB Version: 3.4
@robertwessen
Copy link
Author

this is related to #9419 which was recently addressed.

@geekgonecrazy
Copy link
Contributor

I think #12259 can help with this

@pierre-lehnen-rc
Copy link
Contributor

Fixed by the new videoconf system.

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

No branches or pull requests

4 participants