0

Today I found a video on YouTube that surprised me (https://www.youtube.com/watch?v=Pkc3sE6iKV4). It is by Rob Braxman, a privacy advocate with a lot of expertise.

He talks about all kinds of video conferencing situations. Like one-to-one, one-to-many and many-to-many. It is quite obvious that one-to-many and many-to-many uses a central server as a relay server and therefore no end-to-end encryption is possible.

However, he also says that WebRTC TURN servers (which are used in unfortunate Internet situations such as NAT, firewalls, etc.) cannot provide end-to-end encryption because the server must capture and relay the video blocks. Only encryption during transmission is possible, so that anyone who controls the server can watch the traffic. I thought the TURN relay servers just forward the encrypted data.

The interested part of the video begins around 20min.

Improve this question

2 Answers 2

Reset to default
1

I have not seen the video but I believe you are mistaken/ misunderstanding something.

Those services use a Selective Forwarding Unit (SFU). The turn server is only used for traversing double nat-ed connections.

The SFU combines the incoming streams and re-encrypts them for transport (this is not E2E but is Encrypted at transit) The turn servers just pass back and forth the different packages the receive from the differing participants.

A good Turn server runs I. Encrypted mode so it’s a plain TLS connection. Even without the turn server can only leak the meta data about the connection not the details of the packets themselves (they stay encrypted).

The SFU on the other hand does work on the decrypted data streams, it comes into affect with Jitsi meet when there more than 2 parties involved. They have done some test with E2E encrypted SFU’s but that added the complexity of key management and performance was also affected.

Improve this answer
3
  • I fully agree with you. I had a look at the part of the video and it looks like it gets confusing. From clearly explaining that meta data (IP addresses) gets exposed in case of NAT traversal the description gets murky once TURN "and other things" are involved. You are correct in that just with TURN the connection is still end-to-end encrypted and that the problem only starts if SFU or MFU are involved. Which means that the problem of no end-to-end encryption is real with most systems but the reason for this is not TURN.
    – Steffen Ullrich
    Commented Oct 22, 2020 at 4:41
  • @SteffenUllrich by MFU I think you mean MCU (Multipoint Conferencing Unit, basically what was most used before SFU’s and a whole lot more expensively run.
    – LvB
    Commented Oct 22, 2020 at 19:49
  • 1
    You are absolutely right. Thanks for the correction.
    – Steffen Ullrich
    Commented Oct 22, 2020 at 19:50
0

WebRTC has built-in encryption for peer-to-peer communication as part of the specification. Peers communicate using SRTP (Secure Real-time Transport Protocol) in VoIP session. In E2EE messaging like in WhatsApp and Signal, the caller generates a random 32-byte SRTP master secret and transmits an encrypted message to the recipient using E2E encrypted pairwise (one-to-one) messaging that signals an incoming call, and contains the SRTP master secret.

If the responder answers the call, peer-to-peer SRTP encrypted call ensues. Both peers encrypts and decrypts media stream using that key. At no time this key is known to the XMPP server and signalling server.

TURN is used when either peer is behind a symmetric NAT. TURN plays no role in processing media stream. It only relays SRTP packets between the peers. It can only see header of SRTP. TURN also cannot identify the peers.

Improve this answer

You must log in to answer this question.