Skip to main content
Are my 8x8 Video Meetings encrypted?
8x8 Support

Are my 8x8 Video Meetings encrypted?

Question 

Are my 8x8 Video Meetings encrypted? And is that encryption end-to-end?

Applies To

  • 8x8 Video Meetings
  • 8x8 Standalone Meetings
  • Jitsi

Answer

8x8 Video Meetings can operate in 2 ways, and selection is transparent to the user: peer-to-peer (P2P) or via the Jitsi Videobridge (JVB).

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). Although packets are decrypted while traversing Jitsi Videobridge, they are never stored to any persistent storage and only live in memory while being routed to other participants in the meeting.

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

Why is the media decrypted in Jitsi Videobridge?

Currently, there is no way to do without this in WebRTC, which Jitsi is built on top of. Working around this limitation can cripple usability.

Some services try to achieve end-to-end encryption in multiparty meetings by establishing a full mesh of peer-to-peer connections between participants, but that presents significant issues. From a scalability perspective, this is a very limited approach as utilization of CPU and bandwidth grows quadratically to the number of participants, quickly resulting in degraded user experience.

This is the very reason why services like Jitsi Meet instead opt for video routers -- a.k.a., Selective Forwarding Units (SFUs) -- like Jitsi Videobridge. With SFUs, clients establish a single connection with the video router, and all data goes there. This approach vastly improves resource utilization, but it complicates the encryption situation. At this time, WebRTC cannot negotiate multiparty encryption over a single connection. Every client sets up a separate crypto context with the video router, which then has to trans-crypt the data as it relays it from one client to another.

In the meantime, the situation looks to improve as WebRTC engineers are now working on providing the necessary APIs in the browser so applications can add an additional layer of encryption. This would allow apps to add an end-to-end encryption layer while still allowing SFUs to function.

Additional Information

To learn much more about security and privacy over 8x8's Jitsi platform, click here.