P2P / E2EE + Firefox Confusion

Dear Community,

I’m trying to evaluate whether audio-only calls via https://meet.jit.si/ with only two participants connected are secure enough.

I’ve done some reading but it looks like I’m starting to run into confusion… As per some research, P2P feature is not supported for Firefox (ver 78, Linux). Is that still the case? In my understanding, if it is, that should only mean that the packets have to traverse JVB, but the payload (voice data) should still be end-to-end encrypted, in other words, JVB should not be able to eavesdrop. Is my understanding right?

Say, two peers establish a call via Jitsi Meet . Both use Firefox browser. P2P won’t work for them (at least, by default), right? But the voice data will be encrypted between the two browser instances, right? Will the JVB able to decrypt the voice data?

Please advise.

Hey there, welcome to the Jitsi community!

Correct, this is still the case.

No, incorrect. The JVB decrypts all data and re-encrypts it when sending to the other participants.

P2P will not work for them at all in that scenario.

Data is always encrypted, but by default only hop by hop, so the JVB is able to decrypt it, and it does so as part it’s core functionality.

This is the best we can do in Firefox at the moment, since it does not support insertable / encoded streams and thus don’t support our E2EE implementation either.

If you use a Chromium engine based browser you’ll get P2P working properly and you can add E2EE on top of it if you want.

2 Likes

Thank you very much @saghul for your detailed explanation. Makes sense to me. So, the short of it:

  • In non-P2P mode, data is only encrypted on its way from a given caller to JVB and vice versa.
  • JVB internal workings thus operate on unencrypted data in the case of non-P2P calls.
  • P2P only works in Chromium engine based solutions at the moment (Dec 2021).

That’s the way how JVB appears to be implemented, and I don’t suspect any ill intentions behind this design. However, I suggest that page Jitsi Meet Security & Privacy | Jitsi be improved to describe out in full this model. Perhaps, one could make a diagram to show all hops involved in a 1-to-1 audio call and clearly indicate segments where data stays encrypted. I mean, one diagram for non-P2P mode and one more for P2P mode. That would be very useful to the community, I presume.

However, one more point to clarify is the P2P mode itself. Consider 1-to-1 call. Say, Chromium browser is used at both ends. This way, P2P mode is possible and, as far as I understand, should be enabled by default, transparent to the callers. Correct? If that’s correct, does entering P2P mode implicitly enable true end-to-end encryption between the two callers so that JVB cannot see unencrypted voice data? Or should the callers explicitly toggle so-called E2EE mode via a control in the GUI?

I look forward to your answer. In any case, I really appreciate development efforts behind Jitsi. But encryption modes and data flows should have better explanations at Jitsi Meet Security & Privacy | Jitsi .
Other than that, Jitsi is very user-friendly and efficient tool. Thanks a lot!

From the link:

Jitsi Meet offers very strong protection even if you don’t explicitly turn on e2ee. Here are more details:

Jitsi meetings in general operate in 2 ways: peer-to-peer (P2P) or via the Jitsi Videobridge (JVB). This is transparent to the user. P2P mode is only used for 1-to-1 meetings. In this case, audio and video are encrypted using DTLS-SRTP all the way from the sender to the receiver, even if they traverse network components like TURN servers.

In the case of multiparty meetings all audio and video traffic is still encrypted on the network (again, using DTLS-SRTP). This outer layer of DTLS-SRTP encryption is removed while packets are traversing Jitsi Videobridge; however they are never stored to any persistent storage and only live in memory while being routed to other participants in the meeting.

It is very important to note that when packets are also end-to-end encrypted, this second layer of encryption is never removed (nor can it be)

Since Jitsi is built on top of WebRTC, a deeper look into its security architecture is very important when evaluating Jitsi’s security aspects.

Not sure how else to better describe it.

Correct.

Audio and video are always transport encrypted. When there are only 2 endpoints involved then the transport encryption alone is implicitly end to end encrypted, because there is no other hop.

If a 3rd participant joins, however, media will start to flow through the JVB immediately, and since streams are terminated on the JVB it’ll be able to decrypt them.

So, if you want to make sure you can toggle the E2EE GUI option at all times, and that way you’ll always have the 2 layers of encryption, the transport one and the inner one, which the JVB cannot see.

Thanks!

By the looks of it, the whole page is a bit on a wordy side. Yes, it mentions insertable streams, WebRTC, DTLS-SRTP and even provides a link to an RFC. All of that is very useful indeed. I’m not suggesting to throw away some parts. I do realise that this write-up might have taken much efforts to do. But I’m afraid that only experienced, tech-savvy readers can make sense of it.

For example, paragraph

This is transparent to the user. P2P mode is only used for 1-to-1 meetings. In this case, audio and video are encrypted using DTLS-SRTP all the way from the sender to the receiver, even if they traverse network components like TURN servers.

may trick newbies into thinking that 1-to-1 calls are P2P and E2E-encrypted by default on most occasions. It doesn’t immediately warn the reader about the “Firefox vs Chromium” difference.

For the sake of clarity, it would be way better to provide a summary consisting of short and precise statements (bullet-formatted). For example: “P2P requires that Chromium-based browser/app be used by all callers”. And so on. And, as I mentioned earlier, a diagram would be a plus, too.

More to that, the summary could be problem-oriented, or Q&A style. Consider something like:

Q: What do I do to make sure that my conversation cannot be wiretapped by JVB or any other hop on the way between my browser and my peer’s browser?
A: 1) You and your peer have to use Chromium. 2) … 3) …

The idea of this summary is to address very simple concern: if the reader is afraid of the calls possibly being wiretapped somewhere in-between, what do they do to protect their conversations? The answer should preferably be formatted as a concise set of precise actions required to rule out eavesdropping.

That’s it.