Spec appears to potentially allow violation of the same-origin policy, cross-protocol attacks, etc.

[othermaciej]

WebSockets, limited though it is, was carefully designed to avoid violations of the browser same-origin policy via a handshake an optional use of CORS, and through the distinctive handshake and same-origin requirement, avoid risk of use for cross-protocol attacks. The same holds true for Fetch used with bidirectional streams.

This spec, on the face of it, appears to allow connecting to an arbitrary host:post (for the QUIC transport) or arbitrary URL (for the HTTP3 transport).

Same-origin policy applies protection not only to resources protected by stateful credentials like cookies, but also to resources protected solely by virtue of network position, such as via firewalls.

Furthermore, with this spec, cross-protocol attacks against any QUIC-based protocol may be possible. In addition, by opening up relatively "raw" messaging, the spec may allow for HTTP interactions that are deliberately not exposed through Fetch API for security reasons.

The Security Considerations section does not explain how these attacks are avoided, or alternately, why it is ok that they are allowed. Nor does the explainer give any indication that these types of attacks were considered as part of the threat model.

This seems like a potentially fatal problem with this spec as written, unless I am misreading or missing something. While the use cases are compelling, solving them while addressing security issues in a satisfactory way is the key problem for work in this space.

[vasilvv]

The measures to enforce same-orign policy and to prevent cross-protocol attacks are described in the wire format drafts that are cited in the document. QuicTransport uses ALPN and a special QUIC transport parameter, described here, to prevent those. Http3Transport has a special CONNECT-based handshake it performs to establish a session, described here. Both drafts have Security Considerations sections that go into more detail about that.

[pthatcherg]

Is detailed security design usually in an explainer? The explainer states one of the goals to be "Ensure the same security properties as WebSockets" and then the spec goes into detail about how to address that. Recently, we moved much of that design into IETF drafts that Victor pointed to (and the spec points to).

I'd be happy to put a brief summary of the security design into the explainer if you think that would be better.

[vasilvv]

@othermaciej Does #20 address your concerns, or is there anything else we need to add?

[othermaciej]

I haven't looked at #20 yet but I will! To be clear, I was talking about the proposed spec at https://wicg.github.io/web-transport/, not the explainer. I think it's a good idea for it to explain these security considerations even if some area actually addressed in protocol specs. Part of that is that it's somewhat protocol-generic, and new protocols added need to address these issues as well. And part is so it can be reviewed sanely. I will re-read with the new PR. Thanks for making that update!

[cynthia]

If I understand the status correctly, this is still in a design consideration phase - and a proposal to address this hasn't landed in the spec yet?

[vasilvv]

@cynthia By "this", you mean origin checks and cross-protocol spoofing prevention? In that case, we do call out the need for both; but since this is a wire protocol issue, rather than an API issue, we moved the description of the relevant mechanism into the wire protocol specs (QuicTransport, Http3Transport).

[pthatcherg]

Waiting for othermaciej to verify he's OK with what's in the spec

[othermaciej]

Acknowledged. I'll add this to my queue.

[anforowicz]

@vasilvv, thank you for providing a link to https://tools.ietf.org/html/draft-vvv-webtransport-quic-00#section-3.

I think one concern here is that the server might reply with "web_accepted_origins" set to "*" without realizing that this circumvents not only CORS, but also CORP, CORB, Sec-Fetch-Site and other similar security mechanisms on the web. One way to mitigate this concern would be to check how specific servers behave (e.g. ones hosting sensitive data like email providers or financial institutions). Another would be to gather statistics on how often "*" is used in practice. Have we tried such checks and/or got such data?

/CC @csreis and @mikewest

[vasilvv]

@anforowicz We've updated the protocol to send the origin explicitly; see https://tools.ietf.org/html/draft-vvv-webtransport-quic-01#section-3.2 and #60.

not only CORS, but also CORP, CORB, Sec-Fetch-Site and other similar security mechanisms on the web

I am not sure I understand how any of the listed mechanisms are relevant. The WebTransport servers always know the origin, always knows the manner in which the connection was initiated (via an explicit JavaScript call), and can always reject the connection based on it. If the server decides that the correct way to implement the origin check is "return true", there isn't much we can do.

Another would be to gather statistics on how often "*" is used in practice.

Given that QuicTransport has not even shipped into an origin trial yet, the answer is that there aren't any production QuicTransport servers out there, so we can't really tell yet.

[anforowicz]

QuicTransport has not [...] shipped

@vasilvv - thanks for explaining. I made a wrong assumption that the "web_accepted_origins" might be part of the already deployed QUIC protocol. In this case, it seems to me that the security properties of WebTransport are similar to the security properties of WebSockets (with each requiring an explicit handshake / opt-in).

I am not sure I understand how any of the listed mechanisms are relevant.

My point is that the web server administrators need to be aware that by setting "web_accepted_origins" to "*" they not only opt out of CORS, but also out of these other security mechanisms. Although I guess, maybe all of this has to be implied, because enumerating all the affected security mechanisms might be difficult (e.g. I've just thought about image/canvas tainting as another example).

[anforowicz]

@vasilvv, I've been told that in the most recent revision of the WebTransport draft (https://tools.ietf.org/html/draft-vvv-webtransport-quic-01) the the client provides the Origin and the server decides whether to drop the request (without being required to explicitly opt-in by sending "web_accepted_origins". With this design, it seems likely that the server will just accidentally ignore WebTransport-specific handshake properties (like the client's origin from 3.2.1 in the 01 version of the draft).

[vasilvv]

@anforowicz That was one of the concerns I had too. There was an idea of making the server echo the origin (similar to what CORS does) in order to make this harder to get wrong, but that would add an extra round-trip to the handshake, so we decided against that. At the end of the day, the server authors will know it's there (it has an entire stream dedicated to it), but there isn't much we can do to make sure that the application does something meaningful with it.

[yutakahirano]

We require a custom ALPN value, so it is impossible for a QuicTransport client to talk to a QUIC server which is not aware of QuicTransport. It is still possible that the server accidentally accept a request with an origin to which it doesn't want to talk, but whether it is an implementation bug or a defect of protocol is not clear to me.

[jan-ivar]

WebTransport TPAC notes:

• Most of these sound like protocol issues, and not API surface related. Consider opening issue with the IETF
• We plan to close this issue in a few days if there are no objections, to allow for participants a chance to revisit and look over this older issue.

[ddragana]

@jan-ivar I had a quick look and I think this issue can be closed. This issue should be handle by IETF. "Security Consideration" section in the propose W3C spec sounds reasonable and list all relevant requirements for a transport protocol.

[jan-ivar]

Closing this as mostly resolved. See https://w3c.github.io/webtransport/#privacy-security

New issues will be filed on smaller items not covered there.