1969916 - Local network access restrictions for webrtc

Status: NEW

(Core :: WebRTC: Networking, task, P3)

Description

[Byron Campen [:bwc]]

We have some webrtc-specific work to do on LNA. This is going to involve:

• Adding a local network access prompt before being willing to use remote candidates that appear to be on the local network (either by inspecting the IP address, or seeing an mDNS address)
• The lack of this permission should also prevent the use of STUN/TURN servers that appear to be on the local network
• For http proxy networking, we'll need to ensure that we're using the necko API appropriately

Some questions we want to think about:

• Do we want to require this permission to allow local host/mDNS candidates? This is not really a settled issue yet. It is one thing to disallow sending packets to the local network out of the blue, but what if we receive packets from the local network first? This is a question that does not apply at all to http/s, so I'm not sure that it has been adequately considered in the LNA proposal.
• If an origin has been given persistent capture permissions in the past, do we interpret that as granting persistent local network access? My inclination is "no" on this; having done a facebook call in the past probably should not allow facebook to have at-will access to the local network. Persistent local-network access will need to be established separately.
• If an origin has an active capture, should we by extension allow local network access? I'm leaning toward "no" on this as well; this is a very different kind of permission. getUserMedia isn't bound to any particular peer connection, and while we could look at whether a sender on a given peer connection is attached to a capture stream, the capture stream can easily be shut off without closing the peerconnection. To a user, this would look like the call is over, but it could live on and continue accessing the local network for nefarious purposes without any awareness from the user. We might be willing to gather/expose host candidates (like now), but if we get remote host/mDNS candidates we probably shouldn't use them by default.
• Do we wait until seeing a local network candidate/ice server before asking for this permission? That would mean that in almost all cases, this prompt would not be necessary, which is good.

Comment 1

[Martin Thomson [:mt:]]

https://localmess.github.io/ for context.

I think that we can do several things here, mostly agreeing with the original analysis.

• I don't see any way to make mDNS usage safe here. There's a potential bug in the spec regarding the requirement in Section 8.1 to probe for names you want to use before using them, because that assumes the use of low entropy names. A high entropy name - like the ones we use here - won't have any collision risk. Even if we fixed that, we're still vulnerable to sites providing mDNS candidates that we'll then broadcast to the entire network. We'd only be able to avoid the abuse if our broadcast was guaranteed not to be delivered to other apps on the same host, but I don't think that is how these systems operate (if it is, that would be good and we can perhaps still use remote mDNS candidates; I'm not holding my breath, but it is worth checking).
• We should only show a prompt if there are local network candidates or STUN/TURN servers. That would cut out a lot of unnecessary prompting, which will end up being annoying. That makes timing of the prompt less deterministic when we use trickling, which will drive ICE success rates down, but I think that's workable.
• I don't know about prompting once a site has an active microphone/camera usage. I agree that persistent but inactive permission isn't sufficient. However, this sort of tracking bug is not useful on a site like facebook; it's all the rest of the web where this is useful and that's not a place where we expect a lot of persistent camera/mic permissions. From that perspective at least, it might still make sense to allow local network access as a side effect of having an active session. (If we do, it might make sense to have a pref for blocking that, but maybe the existing mode switch suffices for that.)
• I see no reason to ever allow a STUN/TURN server on loopback. We should modify the spec to make that an error. We can't synchronously throw, but we can reject the setLocalDescription promise.
• If we get STUN probes from the network (via a hairpin, I'd guess, if we're not making our own candidates available) the safest thing to do is show the prompt. We might have to do the same for mDNS lookups (if we can avoid the requirement to broadcast all new names, contravening the spec requirement). That will mean those initial probes will probably fail, but we should persist the permission for LNA, so I don't think this is a long-term problem.

Comment 3

[Jim Mathies [:jimm]]

Note, the team does not currently have LNA work prioritized. Setting to appropriate severity.