A current state of the things
When asked about end-to-end encryption in WebRTC (a technology that is used in almost all applications for audio and video calls), usually the conversation ends up with just a single phrase, that end-to-end encryption in WebRTC is here from the very beginning and that everything is protected by default.
But, as they say – the devil is in the details.
And in reality, most of our nowadays calls are not protected. And first of all, these are group calls, despite the fact that E2EE is here in WebRTC. This is the case, because end-to-end encryption in WebRTC is implemented only between 2 peers / points. Initially, the security system in WebRTC was developed for a point-to-point connection, a single hop, and not for multiple hops between peers.
But nowadays, most calls work through the so-called SFU bridge, which allows to make group calls for 10-20 users.
So, a SFU bridge is the same peer as any other user. All conference participants share media data with each other through this bridge and, accordingly, 2 “hops” are already needed here. The bridge, in turn, can legitimately decrypt the data of each user, because it, in fact, is the same user. And if it is compromised, then it can also send this data somewhere.
In general, not a good encryption in the end.
A good news
Many developers worried about this question several years ago, including Google developers.
And a new thing evolved – WebRTC Insertable Streams, which allows you to make E2EE in WebRTC through any number of hops. In fact – now it works similarly to E2EE in messaging – you can decrypt media data only with a key, which is usually only available for call participants only.
More detailed articles about WebRTC Insertable Streams are here:
- https://webrtchacks.com/true-end-to-end-encryption-with-webrtc-insertable-streams/
- https://webrtcbydralex.com/index.php/2020/03/30/secure-frames-sframes-end-to-end-media-encryption-with-webrtc-now-in-chrome/
And the ‘Explainer – WebRTC Insertable Streams’ itself:
https://github.com/alvestrand/webrtc-media-streams/blob/master/explainer.md
Google is already successfully using it in production – so far so good.
And there is already an alpha implementation from the most popular SFU bridges:
Jitsi: https://jitsi.org/news/e2ee
Janus: https://github.com/meetecho/janus-gateway/pull/2074
Medooze SFU https://twitter.com/murillo/status/1244561622502424576
Conclusion
In general, safe and protected calls are almost here!
One day we switched from HTTP to HTTPS.
Another day the same will happen with E2EE for messaging and calling. Be prepared for it!
