> Because data is never stored in an intermediary server, the transfer is fast, private, and secure.
But WebRTC needs a TURN server for when hole punching/STUN doesn't work when both clients are behind NAT.
Data is never stored in an intermediate server, but it can pass through.
How is the privacy and security ensured that the TURN server won't/can't read your data? Do you just have to trust them? Or is a form of E2EE employed?
I'm surprised this isn't even metioned on the page. Or does this not include TURN servers, and so file transfers just fail between certain peers? (Which it doesn't mention either.)
WebRTC, in fact, merely passes e2e encrypted packets through the TURN server (which, by the way, is only required if both sides are behind symmetric NAT: the vast majority of NAT doesn't cause this problem, though you might need to do STUN).
A lot of cell networks won't work with STUN. I've tried in personal projects to have a home computer with wifi communicate through a stun server to a mobile device using mobile data. It don't work.
> the vast majority of NAT doesn't cause this problem
A WebRTC clients behind an iptables based MASQUERADE NAT will not work without TURN. Which both incredibly common and weird that people designing WebRTC and STUN/TURN/ICE never stopped by netfilter developers to make iptables work out of box with WebRTC.
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.
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.
That's incorrect. What you're describing is STUN, when it works. TURN is what is used when peer-to-peer remains impossible. All data transfer is via the TURN server.
Both clients send a packet to a server, server sends the remote IP to both parties, both parties try to send traffic to either’s remote IP. Unless their nat firewall is evil, this should work.
That doesn't work with "symmetric" NAT, which was specified by the person you are responding to: in that case, you can't rely on even a third party to figure out the port. To the extent to which this NAT paradigm is chosen for its efficient usage of ports, this is fixable using UPnP/NAT-PMP/PCP, but 1) I've (sadly) never seen a WebRTC implementation which takes advantage of these protocols, and 2) usually this isn't chosen for it's port efficiency: it is chosen because the NAT provider is incompetent (or even actively "evil", lol), and so they are almost certainly also not going to support a port mapping mechanism.
Regardless, I'll claim that the real disagreement is more over how common symmetric NAT is: I claim it is very rare, and that the vast majority of NAT isn't symmetric... however, in another thread, the user you are responding to claims that "in [their] country" they've never seen WebRTC work at all. I'd wager that's a pretty local issue, with what probably amounts to a local oligopoly built with similar limitations, but if you live in that world it must be brutal. However, that's not WebRTC's problem: we should implement port mapping in clients and ISPs should, to put it as kindly as feels fair, "fix their shit".
> A symmetric NAT is one where all requests from the same internal IP address and port, to a specific destination IP address and port, are mapped to the same external IP address and port.
My understanding is that it's not "required", but most of the CGNAT routers I've encountered do symmetric NAT, and they force-randomize the source port for each new connection, then keep it fixed for one external ip:port for some "session" duration, defeating traditional hole-punching.
When I've tried to build WebRTC P2P stuff I've experienced this making direct P2P WebRTC connections between CGNAT users nearly impossible, always requiring at least one node with a re-usable hole-punched public udp port or a relay server.
Such CGNAT should also be more likely to support PCP than a normal NAT. It does suck that, AFAIK, no browser has integrated support for this into their WebRTC stacks :/.
But WebRTC needs a TURN server for when hole punching/STUN doesn't work when both clients are behind NAT.
Data is never stored in an intermediate server, but it can pass through.
How is the privacy and security ensured that the TURN server won't/can't read your data? Do you just have to trust them? Or is a form of E2EE employed?
I'm surprised this isn't even metioned on the page. Or does this not include TURN servers, and so file transfers just fail between certain peers? (Which it doesn't mention either.)