Rocket.chat: JitSi Video Chat opens with "undefined" in the URL

[amenk]

Description:

Server Setup Information:

• Version of Rocket.Chat Server: 0.60.4
• Operating System: Ubuntu 16.04 LTS
• Deployment Method(snap/docker/tar/etc): snap
• Number of Running Instances: 1
• Client version: Chrome Version 63.0.3239.132 (Offizieller Build) (64-Bit)

Steps to Reproduce:

1. Click the camera icon
2. Press yes to open meet.jit.si Chat
3. New browser window is opened (as configured)
4. URL is https://meet.jit.si/RocketChatundefinedDwiEcBXcnNkWDkNkuMJzmGfsekJ4zaMHGE

This happens only on some clients, so we end up in different rooms. The undefined string does not seem to belong there.

[robertwessen]

Can confirm the same behavior, worked prior to 0.60, now has _undefined_ inserted in some client's URLs after upgrade. Can reliably reproduce the problem case on Ubuntu 16.04 (Chrome 63 + FF 57) and Win10 (Edge + IE11). Some clients however do not have _undefined_ inserted into the generated link, which means the RC->Jitsi conference integration has a UX breaking issue.

[amenk]

just a wild guess: maybe it was change?

https://github.com/RocketChat/Rocket.Chat/commit/78aa5d32a1f102ca1678d15b561d40ced53a65d9#diff-d4653af8156a866566eb523a4d675429 by @engelgabriel ?

[robertwessen]

@amenk ~looks like that change was part of 0.60.4 , we are running 0.60.1 and see the same problem behavior (I should have mentioned that above). If I had to guess, it feels like a dependency issue around newer Node/Meteor versions introduced at that time as I don't see any direct changes in this code around the time things broke for us. (but I'm not deep in this code :man_shrugging: )~

User fail on my part, that was a 0.60.0 change.

Looking further I think you're correct. The URL constructions I'm seeing in the broken instances are 'Rocketchat'+'undefined'+'RoomID' in the jitsi URL (RoomID just confirmed by sniffing websocket comms). This matches what you highlighted. I suspect the call to RocketChat.settings.get('uniqueID') is the culprit, but before it was hidden by the hashing. Not sure why some clients don't get undefined though.....

[amenk]

If it was hidden by hashing, this would mean also some rooms should not have worked before (users would have gotten different hashes -> cannot see each other). We did not notice such.

@engelgabriel, can you maybe jump in?

[robertwessen]

Yes, you are right.

That call _is_ the source of the 'undefined' though. I just went back to some jitsi URLs generated before 0.60 and the calculated md5sum in those links was in fact md5(uniqueID+RoomID). Now RocketChat.settings.get('uniqueID') is returning 'undefined' instead. It does not explain different users getting different URLs, but it does explain why some now see 'undefined' in the link.

[amenk]

Do you have clients where it does not return "undefined" but an actual uniqueId ?

[robertwessen]

i did another survey of people across multiple browser/OS combos, all the replies I received today were the same, all had 'undefined'...perhaps the original issue was temporal? caching? It's not a scientific survey, although some of the people were the same who previously had the problem (not sure they were using the same OS/browser combo today though).

I'd be curious if there were file upload issues around the 0.60 release for installs using the file system (not GridFS), or iOS push issues, because there are not many other places other than those where RocketChat.settings.get('uniqueID') is used.

[amenk]

okay, will check -- then it actually might be a no-issue.​

[robertwessen]

There is one large issue that derives from this if all clients get 'undefined' though. One channel in particular becomes predictable.

If the public meet.jit.si service is used, _all_ video conferences launched from #general on any install will have a colliding URL of 'https://meet.jit.si/RocketchatundefinedGENERAL' since the RoomID for #general is always 'GENERAL', right?

It's only a matter of time before that channel becomes a variation of chatroulette. :)

[sgala]

+1, we are using the rocketChat+jitsi combo both with our "central" chat+video server and on prem servers for some clients, and we really need to ensure that rooms cannot be easily predicted.

How can we ensure that uniqueID returns something like a reasonably safe UUID for every boot of every install and thus different installs have different uuids? We can inject the value ourselves, I just can't find where is it read from, I can't see it in the config...

[arminfelder]

the problem seems to be, that the return to public-settings/get is not containing the uniqueID at all

[arminfelder]

I guess, the issue could be here:

const records = RocketChat.models.Settings.find().fetch().filter(function(record) { return record.hidden !== true && record['public'] === true; });
packages/rocketchat-lib/server/publications/settings.js
:6

RocketChat.settings.add('uniqueID', process.env.DEPLOYMENT_ID || Random.id(), { 'public': true, hidden: true });
packages/rocketchat-lib/server/startup/settings.js:2

const jitsiRoom = RocketChat.settings.get('Jitsi_URL_Room_Prefix') + RocketChat.settings.get('uniqueID') + roomId;
packages/rocketchat-videobridge/client/views/videoFlexTab.js:62

[robertwessen]

I'm not sure who to bump this up to. @engelgabriel ? you were mentioned before, do you know who might be the best to ask?

Depending on the threat model and deployment context, the current implementation becomes a security/privacy problem for installs with jitsi integration. Right now any one user of a RocketChat instance using the jitsi integration can predict any other jitsi room URL for any other channel or direct message pair. This was never a strong privacy control before 0.60, however previously getting a private jitisi room resulting from a DM was not possible without elevated permissions within RC (to get the uniqueID and calculate the hash) or unless proxy logs or some other info leak was found. This private jitsi room calculation is now trivial for a third party.

[arminfelder]

we should have the md5 re enabled, and the jitsi link generated on the server side, otherwise, we would have to expose the uniqueID

[matt020191]

I am currently running 0.68.0-rc.0 (the latest one) and unfortunately this bug is still present for me. I see the last comment was back in February - was anyone able to get this fixed?

UPDATE 8/10 - still experiencing this problem in 0.68.3
UPDATE 9/5 - still experiencing this problem in 0.69.1

[reetp]

Yup, still in 0.69.1 and I mistakenly missed this and opened #11949

16th Jan - 6th September ??

Devs want us to use Jitsi and not the builtin Web RTC, but leave this broken? I'm also not sure if the UID is required on a self hosted Jitsi instance (I am testing my own Docker instance)? Presumably so.

9632 languishing about as well.

Particularly frustrating when it appears it is known where issues occur but nothing is done to fix it, and it isn't simple to just temporarily patch your own Rocket instance (as opposed to say PHP).

I also think it prevents a lot of people from upgrading which means they then report bugs on older systems that may well have been fixed in later versions, and which just adds to the workload.

[matt020191]

After more issue browsing and testing, I was actually able to resolve part of this problem by following the changes at https://github.com/jitsi/jitsi-meet/issues/312. The Jitsi video chat now loads and works correctly in my RocketChat instance even though 'undefined' is still in the meet URL

[robertwessen]

Part of this has now been addressed (no more undefined in the URL). https://github.com/RocketChat/Rocket.Chat/pull/13342

There still exists a privacy issue though, since now any one user can calculate all jitsi URLs for any user/room combo (including video meetings launched from DMs)...but at least the larger public collision problem is fixed.

I think a feature when launching a new jitsi meeting would be best here. 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 users 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.

If this should be a new Issue completely, id be happy to make one.

[tassoevan]

@robertwessen Please, go ahead. And thank you for link this issue with #13342.