|
|
|
|
|
|
by perenzo
2191 days ago
|
|
|
I did not want to say Jitsi is bad. It is one of the best solutions around. But you still have to trust the server if e2ee is not turned on and more than 2 participants are using it [1]: "This outer layer of DTLS-SRTP encryption is removed while packets are traversing Jitsi Videobridge" I believe it is correct to say, that WebRTC is end-to-end encrypted. What you are referring to is, if you can trust to have a direct connection to the other participant and that you can make sure she is the person she pretends to be. This layer is indeed missing and will be added [2] I would very much appreciate your help on the project to eliminate those concerns. [1] https://jitsi.org/security/ [2] https://github.com/holtwick/briefing/issues/1 |
|
|
What this means is that the packets are encrypted between you and the video bridge and the packets travel unencrypted within the videobridge infrastructure, but at no point does the outside world see the unencrypted stream. Talking to the Jitsi video bridge is just a regular WebRTC session as far as clients are concerned (so any DTLS encryption WebRTC has, the Jitsi call has), I know this because before they had a decent SDK I had to manually wedge my WebRTC calls into it.
If you're looking to add e2ee to your project, you're pretty much left to choose between Olm and Signal Protocol, which are quite similar, but libsignal is GPLv3 while libolm is Apache 2.0.
I've used Olm more intensively over the last two years. While it works, it's great, when it randomly wedges a session for no apparent reason you feel like throwing it out the window.