Is WebRTC traffic over TURN end-to-end encrypted?

Question

WebRTC traffic is encrypted using DTLS - ok. But what about traffic that's relayed over a TURN server?

I'm looking for a reliable resource which confirms that the traffic is truly end-to-end encrypted (because "end-to-end" can sometimes mean several things). So I mean

• NOT that there's an "end-to-end" encryption between a peer and the TURN server.

But rather,

• that it is end-to-end between the peers
• such that it is not decrypted/re-encrypted on the TURN server
• AND that there is no way for the TURN server to get access to the secret

I haven't been able to find a definite answer to this.

Answer 1

The place to look is the TURN proposed standard, RFC 5766. The standard provides a means for relaying UDP packets containing application data between a client and a peer:

Once an allocation is created, the client can send application data to the server along with an indication of to which peer the data is to be sent, and the server will relay this data to the appropriate peer. The client sends the application data to the server inside a TURN message; at the server, the data is extracted from the TURN message and sent to the peer in a UDP datagram. In the reverse direction, a peer can send application data in a UDP datagram to the relayed transport address for the allocation; the server will then encapsulate this data inside a TURN message and send it to the client along with an indication of which peer sent the data.

The highest layer that TURN parses is the UDP layer. It does not understand or modify the application data layer (in your case, the WebRTC protocol). The standard says:

An application wishing to ensure that its data is not altered or forged must integrity-protect its data at the application level.

This implies that you can integrity-protect your application data, and TURN will relay it without modification. You can also look at the details of the TURN protocol (which I won't repeat here) that show that it merely wraps and forwards application data.

Finally, the standard says this on eavesdropping:

Confidentiality for the application data relayed by TURN is best provided by the application protocol itself, since running TURN over TLS does not protect application data between the server and the peer. If confidentiality of application data is important, then the application should encrypt or otherwise protect its data. For example, for real-time media, confidentiality can be provided by using SRTP.

The recommendation in this excerpt is to protect confidentiality by encrypting application data with a protocol such as DTLS-SRTP, which WebRTC uses.

Because TURN does not interpret or modify application data, it doesn't add any security vulnerabilities to WebRTC application data traffic that wouldn't be present without using TURN. WebRTC data is encrypted between WebRTC endpoints.

Now, no one can guarantee that there is "no way for the TURN server to get access to the secret." A rogue TURN server could attempt a man-in-the-middle attack on your connection just as easily as anyone else who can intercept your network packets. It's only true that using a TURN relay doesn't weaken WebRTC security.

As long as DTLS is implemented and used properly and assuming the DTLS algorithms and ciphers are secure, WebRTC traffic should be secured end-to-end. Part of using any SSL-based scheme requires verifying the certificate of the other endpoint, just like HTTPS. And just like HTTPS, this will require a prior out-of-band exchange of certificate identity or use of a trusted third-party. And just like HTTPS, if certificates are not properly verified then the door will be open for a MITM attack (by anyone, not just TURN servers).