- From: Lenny via GitHub <sysbot+gh@w3.org>
- Date: Mon, 22 Nov 2021 10:38:03 +0000
- To: public-webrtc-logs@w3.org
> When it talks to STUN/TURN servers, isn't at least port blocking in effect there? It seems weird if there are no policies governing those connections. From the [spec](https://w3c.github.io/webrtc-pc/#dom-peerconnection-addicecandidate): > A candidate is administratively prohibited if the UA has decided not to allow connection attempts to this address. > > For privacy reasons, there is no indication to the developer about whether or not an address/port is blocked; it behaves exactly as if there was no response from the address. > > The UA MUST prohibit connections to addresses on the [Fetch] block bad port list, and MAY choose to prohibit connections to other addresses. That being said, IIRC one can still exfiltrate data to arbitrary servers by crafting TURN credentials if that is left open. Furthermore, I'm almost certain that, due to the complexity of the state machine, implementations would have to place a whole bunch of "WebRTC is turned off" guard checks, so one can interact with the PC state machine safely in the "off" mode. -- GitHub Notification of comment by lgrahl Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/pull/81#issuecomment-975385608 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 22 November 2021 10:38:05 UTC