Is the Jitsi E2EE discussion about 'real' E2EE?

Hi

I recently read this on WebRTC security: https://webrtc-security.github.io/
It has one reference to E2EE - end to end encryption.

Can I confirm my summary interpretation with this esteemed group?

Basically, if we start with the assumption that a browser offers a trusted sandbox for video initiation/termination (sender to receiver) - a BIG assumption. Then we apply DTLS and other Web security services we encrypt the channel of communication to lock out MitM.

However this is NOT the same as E2EE as offered by services like Webex or perhaps Whatsapp, because the service providers themselves cannot decrypt the content as they don’t have the keys. Whereas in WebRTC a nation state could demand access to the video content from the service provider by demanding key access.
So for those people worried about state interference WebRTC does not provide E2EE as its “normally” used at the media level (e.g. as Zoom recently got castigated for stating in their platform when in fact all they offered was TLS/SSL…although I realsie WebRTC is better than TLS/SSL alone due to sandboxed end points).

Please comment on my last statement - which i am not sure is correct.

Well, recent Jitsi has a ‘true’ E2EE feature. I have already commented on it here and of the 2 remarks I did, one about key exchanges really does not apply since the encryption key is not managed at all by Jitsi, it’s supposed to be exchanged by any means such as mail, smoke signals, secret handshake or whatever. So the Jitsi server does not know the encryption key and in this sense it is E2EE (note that I have not audited the software :-))

However if the Jitsi server is sending the Javascript code that is managing the encryption, the second remark still applies. If the server is compromised, it can send boobytrapped Javascript that can do anything. So unless there is a non web client that can be audited off line and built from source, (Electron does not apply, it’s just a glorified iframe), it’s not a ‘true’ E2EE, particularly not state agent proof. In comparaison the fact that a web browser is not a perfect sandbox is a really small detail. The browser itself could also be compromised by a state agent (it’s usually subject to auto-updates now)

All in all, it’s still an interesting development and actually already usable despite the ‘beta’ tag. Why not using it on meet.jit.si ? it’s really an additional security feature… Effectively it kills the possibility that a rogue operator at a server center installs a private Jibri. Not a great risk, but theoretically it could happen. Beyond that, no security is ever perfect

1 Like

Thanks, a useful response.
We are looking for experienced jitsi integrators who can help us implement a secure integration, any thoughts on who to approach?