[filleokus]

Hmm. I'm not a WebRTC pro but looked into it recently for a hobby project and felt that the typical WebRTC TURN implementation still leaves the TURN server in a quite trusted position. My rough understanding:

- (1) Each client generates a key pair

- (2) The fingerprint of the public key is part of the SDP message each client generates

- (3) The SDP message is somehow exchanged between the clients, out of band, and the session is started. The client's verify the remote peer using the public key from the SDP message.

The problem is that it's not really feasible in most circumstances to exchange the full SDP message out of band, so instead the service provide some mechanism to map a shorter ID (typically in a URL) to a centrally stored copy of the SDP. I think this might be where it happens for filepizza [0].

This means that a malicious file sharing operator, being in control of both the TURN service and the out-of-band signalling mechanism, could just MITM the DTLS connection and snoop on all the data going by. The peer's think they have each others public keys but they just have two keys owned by the server.

[0]: https://github.com/kern/filepizza/blob/main/src/channel.ts

[numpad0]

Only the initial SDP needs to be fudged. The attacker could just set up two clients that pretends to be the sender/recipient. Then the data can just go through regular Google TURN servers.