4 ms·

> 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

> 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.)

robertlagrant 2y ago
Good point. I didn't think of that.
phailhaus 2y ago
OP can just not use a TURN server, and it won't work for double-NAT traversal. I did this in a side project to avoid the security risk.
eptcyka 2y ago
But you can punch holes even when both clients are behind NAT.
- ranger_danger 2y ago
  How so? With both users behind symmetrical NAT? TURN does not count as punching holes IMO.
  - eptcyka 2y ago
    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.
    - ranger_danger 2y ago
      That's no longer p2p, that's using a relay server like TURN
      - eptcyka 2y ago
        It is p2p, the middle server isn’t relaying traffic.
        frontfor 2y ago
        If TURN is used, then it absolutely is. Please read the comments above.
    - saurik 2y ago
      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".
      - nikisweeting 2y ago
        CGNAT is increasingly common for large ISPs as IPv4 gets expensive. There are entire regions of brazil where all residential internet is CGNAT'ed, making any video calls between those users symmetric NAT.
saurik 2y ago
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).
- deleted 2y ago
  [deleted]
- ranger_danger 2y ago
  > the vast majority of NAT doesn't cause this problem Hard disagree, I've yet to meet anyone in my country that has gotten any WebRTC service to work at all.
  - saurik 2y ago
    FWIW, this doesn't actually imply we disagree, as maybe the vast majority of NATs aren't in your country ;P... we could both be right!
- polishdude20 2y ago
  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.
- happosai 2y ago
  > 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.
ivanjermakov 2y ago
In WebRTC, TURN server is only used to establish a data channel. After that, data transfer us peer-to-peer. https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Signaling_and_video_calling#signaling_transaction_flow https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/...
- crazygringo 2y ago
  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.
gloosx 2y ago
TURN or STUN server can use the DTLS transport in order to encrypt the traffic. So you know it's secure if you are using turns:// protocol and verified the certificate just like it works with https:// https:// https://datatracker.ietf.org/doc/html/rfc7350 https://datatracker.ietf.org/doc/html/rfc7350
- filleokus 2y ago
  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 https://github.com/kern/filepizza/blob/main/src/channel.ts
  - numpad0 2y ago
    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.

robertlagrant 2y ago

Good point. I didn't think of that.

phailhaus 2y ago

OP can just not use a TURN server, and it won't work for double-NAT traversal. I did this in a side project to avoid the security risk.

eptcyka 2y ago

But you can punch holes even when both clients are behind NAT.

ranger_danger 2y ago
How so? With both users behind symmetrical NAT? TURN does not count as punching holes IMO.
- eptcyka 2y ago
  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.
  - ranger_danger 2y ago
    That's no longer p2p, that's using a relay server like TURN
    - eptcyka 2y ago
      It is p2p, the middle server isn’t relaying traffic.
      - frontfor 2y ago
        If TURN is used, then it absolutely is. Please read the comments above.
  - saurik 2y ago
    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".
    - nikisweeting 2y ago
      CGNAT is increasingly common for large ISPs as IPv4 gets expensive. There are entire regions of brazil where all residential internet is CGNAT'ed, making any video calls between those users symmetric NAT.

saurik 2y ago

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).

deleted 2y ago
[deleted]
ranger_danger 2y ago
> the vast majority of NAT doesn't cause this problem Hard disagree, I've yet to meet anyone in my country that has gotten any WebRTC service to work at all.
- saurik 2y ago
  FWIW, this doesn't actually imply we disagree, as maybe the vast majority of NATs aren't in your country ;P... we could both be right!
polishdude20 2y ago
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.
happosai 2y ago
> 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.

ivanjermakov 2y ago

In WebRTC, TURN server is only used to establish a data channel. After that, data transfer us peer-to-peer. https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Signaling_and_video_calling#signaling_transaction_flow https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/...

crazygringo 2y ago
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.

gloosx 2y ago

TURN or STUN server can use the DTLS transport in order to encrypt the traffic. So you know it's secure if you are using turns:// protocol and verified the certificate just like it works with https:// https:// https://datatracker.ietf.org/doc/html/rfc7350 https://datatracker.ietf.org/doc/html/rfc7350

filleokus 2y ago
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 https://github.com/kern/filepizza/blob/main/src/channel.ts
- numpad0 2y ago
  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.