[Connection-Allowlist] Implement allowlist integration with WebRTC. [chromium/src : main]
Andrew Verge (Gerrit)
Message from Andrew Verge![]( "Open in Gerrit")
Set Ready For Review
Related details
- Andrew Verge
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Andrew Verge (Gerrit)
Andrew Verge added 1 comment![]( "Open in Gerrit")
Hi Harald,
I'm seeking some WebRTC expertise on this CL. The rough idea is:
- A document is served with a Connection-Allowlist header. No socket should be created to any network endpoint that is not allowlisted by this header.
- The network service holds a `network_restrictions_id` per document, and maps this ID to a list of URLPatterns for network endpoints in the allowlist.
- This allowlist mechanism should apply to WebRTC peer connections, DNS resolution, and signaling.
- Signaling is not specified, and can be done with HTTP, Websockets, etc. So that's out of scope for this CL.
- That leaves P2P sockets and DNS, which are covered by this CL.
I'm trying to understand a few things:
1. If the changes I have made here are sufficient to prevent any network requests related to WebRTC from going out. My assumption is yes, since no P2P sockets can be created for peers, and no DNS requests can be made in the establishment of P2P connections.
2. How often DNS is actually used for the initiation of peer connections, or if it's more common for peers to be identified in terms of IP+Port pairs. Even if we can block connections to specific IP+Port pairs, it's not super realistic to expect site developers to allowlist specific IP addresses, vs. more human-understood constructs like hostnames.
3. If this behavior is even worth pursuing due to the complexity involved. IIUC in order for a WebRTC connection to work, we'd have to allowlist:
- The signaling server for communicating data between peers
- Every possible candidate (direct connection IP, outcome of STUN request, TURN servers, etc)
If in practice, developers can't reliably enumerate all of these endpoints, then maybe we need an alternative approach that isn't "allowlist a select few endpoints."
I added you since you're an OWNER of services/network/P2P, but feel free to assign additional reviewers or delegate. I'm also happy to discuss this offline, write a doc, etc, if that would be easier. Thanks!
Related details
- Harald Alvestrand
- Xiaochen Zhou
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Harald Alvestrand (Gerrit)
Harald Alvestrand added 1 comment![]( "Open in Gerrit")
I'd like to discuss the architecture of this proposal in relation to WebRTC before diving into code.
The issue with WebRTC is that the peers *do not have hostnames*, and their IP addresses are unpredictable at runtime (resolved using the ICE probing mechanism and mdns for local connections).
When we discussed this in the context of CSP, the more-or-less conclusion was that the only restriction that made sense was "restrict all" or "allow all". There's an intermediate stage of "restrict to known servers", which says that you can only use WebRTC in client/server mode, not P2P mode, but at the time of the CSP discussion, this was not seen as worth making.
Do you have evidence that there's a customer demand for a restriction function that will allow WebRTC only in client/server mode?
Related details
- Andrew Verge
- Xiaochen Zhou
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Harald Alvestrand (Gerrit)
Harald Alvestrand added 1 comment![]( "Open in Gerrit")
The CSP spec discussion ended up here, I think:
Harald Alvestrand (Gerrit)
Harald Alvestrand added 1 comment![]( "Open in Gerrit")
Found the spec discussion in https://github.com/WICG/connection-allowlists/issues/6 - let's have a conclusion on that thread before attempting to land code.
Andrew Verge (Gerrit)
Andrew Verge added 2 comments![]( "Open in Gerrit")
Found the spec discussion in https://github.com/WICG/connection-allowlists/issues/6 - let's have a conclusion on that thread before attempting to land code.
Sounds good, will continue further discussion there. Thank you!
I'd like to discuss the architecture of this proposal in relation to WebRTC before diving into code.
The issue with WebRTC is that the peers *do not have hostnames*, and their IP addresses are unpredictable at runtime (resolved using the ICE probing mechanism and mdns for local connections).
When we discussed this in the context of CSP, the more-or-less conclusion was that the only restriction that made sense was "restrict all" or "allow all". There's an intermediate stage of "restrict to known servers", which says that you can only use WebRTC in client/server mode, not P2P mode, but at the time of the CSP discussion, this was not seen as worth making.
Do you have evidence that there's a customer demand for a restriction function that will allow WebRTC only in client/server mode?
The issue with WebRTC is that the peers do not have hostnames, and their IP addresses are unpredictable at runtime
This was my suspicion (I mentioned it a bit more in the WICG issue you found), glad to hear it's as awkward to allowlist as it sounds!
When we discussed this in the context of CSP, the more-or-less conclusion was that the only restriction that made sense was "restrict all" or "allow all".
I think following the CSP pattern makes sense here as well.
Do you have evidence that there's a customer demand for a restriction function that will allow WebRTC only in client/server mode?
We don't have any specific WebRTC use cases in demand right now. I'm more concerned about preventing WebRTC from being a bypass for the Connection-Allowlist header, and it sounds like a "block all" flag provides an easy fix for that part.
Related details
- Harald Alvestrand
- Xiaochen Zhou
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Harald Alvestrand (Gerrit)
Harald Alvestrand added 1 comment![]( "Open in Gerrit")
So should this CL go back to "WIP" status until the discussion on how it should behave has concluded?
Related details
- Andrew Verge
- Xiaochen Zhou
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Andrew Verge (Gerrit)
Andrew Verge added 1 comment![]( "Open in Gerrit")
So should this CL go back to "WIP" status until the discussion on how it should behave has concluded?
- Harald Alvestrand
- Xiaochen Zhou