[clawoo]

> This outer layer of DTLS-SRTP encryption is removed while packets are traversing Jitsi Videobridge

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.

[perenzo]

Thanks for the feedback, I'll take Olm/Matrix and Signal into consideration, although I believe for the described purpose of Briefing the current implementation is sufficient and secure.

[a1a1a1a1a1a1]

Not sure if this is possible with the current WebRTC api, but if you could expose the dtls public keys for the current and remote sessions somewhere, that would help to reduce the risk of MITM attacks. Users would at least have the option of manually verifying keys through another channel.

edit: it looks like you can find info in the RTCSessionDescription.sdp property. The remoteDescription and localDescription should each have key fingerprints in lines with "a=fingerprint:..."