E2ee key set up changed?

Hi,

Most of my staff works remotely, so we start our day with a Jitsi together. We use the electron app.

As we discuss sensitive things in our meetings, we use both the password and an e2ee encryption key.

That worked fine until this morning. As of this morning there is no option to set an e2ee key anymore. There is only a slider to enable e2ee (or turn it off).

Is that permanent? Is there any reason behind that (it seems less secure as people no longer need a key/password to get included in the encrypted conversation)?

Is there a way of being made aware of changes like that before (or as) they happen?

Our staff received instructions on how to set up and join the meetings; every time there are changes in how to set up or join meetings it creates some confusion and delays as people are unsure how to join the meetings (not everyone is equally tech savy :slight_smile: ). It will be helpful if I could give them a heads up when it is going to look different to enter the meeting.

Thanks

Yes, I have noticed it also on my server (based on nightly build versions of Jitsi Meet):

Maybe I am wrong but in my opinion this change is part of the intended development to perform automatic key exchange in the background (similarly as performed already in the matrix/element.io environment), with Jitsi Meet the key is generated from the URL hash and distributed/circulated between the conference participants, therefore manual key input is not required anymore. Still, each participant has to turn on e2ee function manually to enable it.

This is very convenient but gives the impression for the user that he/she hands over “part of the security” (= the manually created and probably through a secure channel distributed e2ee key) to the software.
However, everything is open-source…

Thanks

I saw on github that they pushed some e2ee stage 2 commits recently as part of ongoing development, that handled automatic key generation and distribution in background for e2ee, probably that just hit meet.jit.si site.

Hey there!

Yes, we are making some changes to the E2EE implementation. It’s still experimental, but it’s taking shape.

What you see now is a E2EE channel through which randomly generated keys are exchanged (and rotated when a participant joins / leaves). We are in the process of adding user verification to this.

2 Likes

Dear Saul,
congrats to the progress and commitment of the Jitsi e2ee implementation.
Very impressive & highly demanded in times of declining online privacy.
Thx a lot! MS

Thanks for the kind words @Mr_Smith! Apologies for the breakage, ideally we’d have waited for verification to be ready, but we hit a couple of important bugs (not E2EE related) that prompted a new release and the current E2EE changes were already merged in order to avoid a single giant PR. Oh well.

Hi,
I have two questions:

  1. Is e2e enable by default now? Without any setting? How can an user know it?
  2. According to this, is there a unique e2e channel among each pair of participants and each participant shares his own symmetric encryption key? If so, just the key exchange is e2e, while not the traffic.

Thank you

No, you need to enable it manually. The toggle switch in the security dialog, you can access it with the shield icon.

There is a unique communication’s channel between each 2 participants, yes. Then each participant shares a randomly generated (symmetric) key which is rotated / ratcheted when other participants join. The server has no access to the key, hence the traffic is end to end encrypted.

Ok, but now there is not any e2e specific password into the shield option, just meeting password. Even lobby room option is not present.

Right, the server has not access to the traffic. However, the traffic is not e2e encrypted since the symmetric key of each user is shared in the group/meeting. So if an attacker is able to enter into the group, it can read all the traffic. This is the same problem that affects signal and it is still unsolved.

Because it’s randomly generated. You no longer need to provide one.

The lobby requires some backend configuration for it to be available. If you are running your own server then you may need to configure that.

I don’t think it’s quite the same problem. If an attacker already made it to your meeting then there is not much that can be done, they are in. That’s why the idea here is to have layers. The password / lobby / JWT token / XMPP auth is what prevents users from joining the conference. One in olm’s E2EE will prevent anyone from snooping.

Not that even if an attacker who is passively recording all media traffic joins, gets all the keys, then gets kicked out, won’t be able to decrypt any media after they left because keys are rotated.

We may bring back the “unmanaged” E2EE key mode, we are still heavily working on this. Thanks for the feedback!

Because it’s randomly generated. You no longer need to provide one.

Well, so if I enable meeting password, it becomes e2e encrypted. Correct?

The lobby requires some backend configuration for it to be available. If you are running your own server then you may need to configure that.

I’m using the official jitsi instance.

I don’t think it’s quite the same problem. If an attacker already made it to your meeting then there is not much that can be done, they are in. That’s why the idea here is to have layers. The password / lobby / JWT token / XMPP auth is what prevents users from joining the conference. One in olm’s E2EE will prevent anyone from snooping.

The encryption is not e2e, but you solved the problem of authentication and so the attack is very difficult to perform.

We may bring back the “unmanaged” E2EE key mode, we are still heavily working on this. Thanks for the feedback!

No thank, it is better in this way, otherwise it is necessary an out of band channel for key exchange.

No. Adding a meeting password and e2e encrypting the media are 2 separate things. The former prevents people from joining your meeting. The latter prevents the infrastructure owner (or any other entity capable of wiretapping the traffic) from eavesdropping.

That’s very weird, we have it enabled, I can see it. Can you reliably reproduce this? What browser and version are you using? Is there any error in the console logs?

No. Adding a meeting password and e2e encrypting the media are 2 separate things. The former prevents people from joining your meeting. The latter prevents the infrastructure owner (or any other entity capable of wiretapping the traffic) from eavesdropping.

I’m asking this since the option about e2e encryption into shield options is not present anymore as I wrote earlier.

That’s very weird, we have it enabled, I can see it. Can you reliably reproduce this? What browser and version are you using? Is there any error in the console logs?

Now, it is working again (the last 3 days did not). I’m using brave 1.15.72 and brave-beta browser 1.16.59 both based on chromium 86.

Ah, I see. Did it ever work in Brave? On Chrome you need an origin trial, or you can force it by enabling the “experimental web platform features” flag in chrome://flags. Can you try that with Brave?

Ah, I see. Did it ever work in Brave? On Chrome you need an origin trial, or you can force it by enabling the “experimental web platform features” flag in chrome://flags. Can you try that with Brave?

Of course, it always worked since the first implementation. Now it only works with the experimental setting enabled. I tried with chrome 86 with the same result. Did you change something on jitsi side? Or something is changed on chromium side?

I believe something has changed in the Chrome side.

Hi,
I think that it could be something on jitsi side. I tried with brave together, that is a custom instance of jitsi provided by brave. It has e2ee option into shield without enabling any flags. The instance of brave together does not seems to be the latest used by jitsi, but I do not know how to check this.

Turns out our origin trial had expired :man_facepalming: It’s now refreshed so things should be back to normal.