Does CONNECT request mean WebTransport should use fetch?

[annevk]

WebSocket uses fetch for the handshake, meaning all kinds of security checks automatically apply. Now that WebTransport has a similar handshake, perhaps it should use fetch to execute it?

See https://fetch.spec.whatwg.org/#concept-websocket-establish.

[ricea]

Agreed in principle. The details may differ. As with WebSocket, we'd like to avoid preflights. Unlike WebSocket, we can probably avoid them even for private network access, since a WebTransport connection can't be used to forge an HTTP request. WebTransport throttling probably will be different from WebSocket, but it hasn't been designed yet.

[ricea]

I originally said "handshakes" instead of "preflights" in the above message. Corrected.

[letitz]

a WebTransport connection can't be used to forge an HTTP request

Can an application build its own HTTP request, serialize it and send it over WebTransport? My ignorance as to the transport part of WebTransport is showing - maybe messages sent over WebTransport cannot be confused with HTTP/3 requests. I guess my question is: can you explain why that is true?

[annevk]

I think apart from the handshake which is ordinary HTTP (though also requires an HTTP/3 connection) it will use its own frame type (WEBTRANSPORT_STREAM, https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http3).

[letitz]

Makes sense! In order to exempt WebTransport handshakes from Private Network Access preflights, I would like to understand what malicious users could inject into the handshake. Are there any user-controlled headers or header values, for example?

[yutakahirano]

cc: @vasilvv

Is it good to call https://fetch.spec.whatwg.org/#concept-fetch?

1. We need to keep the HTTP/3 stream alive as long as the WebTransport session is alive. How can we say so with it?
2. Calling https://fetch.spec.whatwg.org/#concept-fetch implies we attach headers such as accept-language, user-agent and so on.

Having https://fetch.spec.whatwg.org/#concept-fetch support WebTransport would be good if WebTransport needed cookie / authentication / redirect / caching / CORS preflight, but WebTransport doesn't.

We need to check CSP, but that can be done in https://w3c.github.io/webtransport/#webtransport-constructor.

For user-controlled headers, please see #263.

[annevk]

WebTransport does need port blocking, but I plan on moving that to "obtain a connection" so that would work.

[yutakahirano]

I think we don't need to resolve this by the initial release.

[annevk]

#309 would also be handled by Fetch, although the current setup around that is somewhat shaky admittedly.

[yutakahirano]

Hmm... I don't think Fetch's termination would be good for #309 (or #127), as WebTransport's termination is more complex than fetch's termination. WebTransport is similar to WebSocket which has its own logic on unloading.

[jan-ivar]

@yutakahirano I notice the spec references fetch algorithms now. Is this issue still relevant?

[yutakahirano]

Currently WebTransport uses the "obtain a conneciton" procedure. This issue is whether we want to use the "fetch" procedure. So, they are different from each other.

[jan-ivar]

Currently WebTransport uses the "obtain a connection" procedure. This issue is whether we want to use the "fetch" procedure. So, they are different from each other.

@annevk it seems we interface with fetch at a low level here. Is this sufficient to provide the "kinds of security checks automatically" that you reference? If, not would you mind listing the missing ones? Thankls

[annevk]

I'm not sure which are relevant, but there is:

1. Referrer handling, including referrer policy enforcement
2. CSP
3. Port blocking (I hope to move this into connection establishment at which point it would be shared)
4. HSTS handling (hopefully not relevant as it's always secure?)
5. Mixed Content (hopefully not relevant as it's always secure?)

There's some other things there that's probably not relevant per @yutakahirano's comments above as the handshake does not follow redirects, does not have cookies, does not do HTTP auth, etc.

[annevk]

I guess setting the Origin header is another example: #368.

[jan-ivar]

@annevk Thanks, that seems to leave origin and csp.

Since we have separate issues on those two (#59 on CSP) can we close this?

Our should we wait until you have moved port blocking?

[annevk]

So there's no referrer?

Port blocking is tracked by whatwg/fetch#889, though currently that's not being worked on that I know. I've been meaning to get back to it, but I think it would really benefit from someone with more expertise.

It does seem good to track port blocking on this repository as well, so folks looking at what is still outstanding know that it is an issue.

[martinthomson]

There is no intent to send Referer with the request. Origin should suffice (and we have a plan for fixing #368).

[jan-ivar]

We're already tracking

• CSP policies for WebTransport? #59
• Port blocking #229
• Where is the value of the Origin header set? #368

@annevk is this sufficient to close this issue?

[annevk]

Thanks for the pointers!