Share some connection infrastructure with Fetch

[annevk]

I think there are basically two reasons why we would want centralized connection management in the platform:

• Consistent handling of overrides of resolving names (domains), e.g., mapping localhost to the loopback address, as discussed at Incorperate let-localhost-be-localhost whatwg/fetch#1118.
• Consistent requirements on partitioning of all aspects of the connection. https://fetch.spec.whatwg.org/#network-partition-keys in Fetch is now used for connections and the HTTP cache, but it should also apply to the DNS cache, etc. Having those kind of requirements once would be beneficial. Also in case we ever decide to adjust them.

(See also w3c/webtransport#128.)

[alvestrand]

Consistent handling would also include the blocked ports list.

[annevk]

Fetch currently enforces that at a different point and we would not want to block those ports for WebTransport I believe, but if that needs to be shared with WebRTC we should make that work, yes.

[alvestrand]

WEBRTC just added a reference to the blocked ports list to the webrtc spec because of a known exploit that it would help against, which is why I pointed it out as a shared piece of infrastructure.

I do think WebTransport needs to respec a blocked ports list.

[martinthomson]

I think that it makes sense to share name resolution and even socket establishment (if that is even large enough to bother factoring out into common code).

If you go beyond socket establishment to connection establishment and pooling, then that doesn't apply to WebRTC. Even when it comes to TURN, the connection management is fundamentally different to what goes on with an HTTP proxy.

A big question here is what, if anything, we do for policy enforcement (I can't find the original issue here, but I do remember discussing this on several occasions). Any solution we come up with for managing connections to hosts that are identified using certificate fingerprints will want to be shared with WebRTC and WebTransport. My initial thought is a connect-src special label that covers all identifiers of that type, but it needs work to be sure. No matter what solution we end up with, it makes sense to share that piece of infrastructure.

I don't think that we can avoid policy enforcement for ever; people use connect-src to prevent data exfiltration and having common hooks would be good.

I don't believe that the blocked ports are necessary for WebRTC or WebTransport as both protocols have fairly good consent/address validation arrangements. I say that only cautiously as QUIC has some exposure to request forgery attacks and it might turn out that we need something. I don't know whether anyone has done a proper analysis for DTLS and STUN to know if WebRTC is vulnerable, so that might be worth checking too.

[alvestrand]

@martinthomson read up on "NAT slipstream". It used WebRTC and TURN as a carrier for some of the attacks.
WebRTC has fairly good protection against improper access to WebRTC listeners; the blocked ports list is all about ensuring that it can't be used to attack other resources.

[martinthomson]

Thanks @alvestrand, I'd forgotten that attack. That is a request forgery attack that exploits vulnerabilities in commonly deployed SIP ALGs. It's a pity that STUN and TURN are so poor when it comes to request forgery given their function. If your claim is that this is common with (unsecured) HTTP, that is true, but it probably worth noting that this commonality will be a case-by-case thing.

[alvestrand]

The network partition key (https://fetch.spec.whatwg.org/#network-partition-key) may be a sharable object.

[jan-ivar]

@annevk to unstuck this, would you be able to provide examples or guidance (or even a PR) with how and which algorithms you imagine WebRTC invoking in fetch here?

[annevk]

I'm slowly making progress on enabling this together with @ricea. The idea is that WebRTC would at some point hook into https://fetch.spec.whatwg.org/#concept-connection-obtain (or perhaps something lower-level as mt points out above), with parameters that make sense for it. That would then take care of any domain resolving (if needed) and setting up and returning a connection.

My hope is that we can also move some other logic there, such as port blocking, what localhost means, etc. (I think since mt's comment above implementations have reached agreement on sharing port blocking logic across HTTP/WebRTC/WebTransport connections, with the exception of one or two ports that are safelisted for WebRTC use.)

[alvestrand]

Anne, I'm having a bit of trouble understanding how "obtain a connection" could be a common merge point.
To start off with, WebRTC doesn't use hostnames in the common use case (it does use MDNS hostnames in some cases, and it's possible to use hostnames too, but the by-far majority of usages use IP addresses).

I do appreciate that @ricea is trying to help, but having someone who knows the WebRTC networking stack (ICE, STUN and all that machinery) in the loop is probably vital, so that we don't generate proposals that don't make sense in the WebRTC context.

[annevk]

Agreed. We're still in the process of ensuring Fetch, WebSocket, and WebTransport are aligned and it might make sense that WebRTC only reuses some aspects. I'd love to chat once we're closer. Here are the things that come to mind with regards to sharing:

• Keying. Any kind of cache and connection pooling should take into account the network partition key.
• Port blocking. While not currently the case, it's our plan to enforce this while obtaining a connection.
• Proxies. It would be ideal that if there's a proxy and it doesn't do UDP, the browser doesn't attempt to do UDP. (To be clear, this could use input. It's not clear how realistic this is.)
• CSP. I think it would make sense if part of CSP was enforced here.
• online/offline events. These events are somewhat problematic as they fire around the same time across tabs, creating a cross-site communication channel and privacy leak. It would be better if they only fired after the global state change once a tab is focused by the user. However, unless we also make and enforce the state per tab, this would be meaningless. (It's still somewhat tricky to avoid leaks entirely in the going offline case, but I think we can improve on the status quo at least.)