Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ambiguity in CORS-like mechanism in the handshake #60

ericlaw1979 opened this issue Sep 18, 2019 · 3 comments


Copy link

commented Sep 18, 2019 says: “All transports must allow the server to filter connections based on the origin of the resource originating the transport session.” but this doesn’t seem to be quite what is specified in which says "QuicTransport uses a QUIC transport parameter to provide the user agent with an origin whitelist. The origin is not sent explicitly, as TLS ClientHello messages are sent in cleartext; instead, the server provides the user agent with a whitelist of origins that are allowed to connect to it."

The QuicTransport spec thus imposes two serious limits:

  1. The server MUST know, a priori, all hosts to which it may want to allow to communicate with it. There's no possibility of implementing a blocklist, or a sub-origin wildcarding scheme (e.g. *
  2. The server has no trustworthy means of knowing the origin of a connection, unless it advertises only a single origin in web_accepted_origins.

This comment has been minimized.

Copy link

commented Oct 2, 2019

This is true.

Here's an alternative we discussed that would solve these issues:

  1. Have a hardcoded unidirectional stream ID for origin to be sent from client to server
  2. If server doesn't like it, it closes the connection

This avoid any extra RTT before sending data and gives the server all the flexibility that it needs.

Also, we should leave open the flexibility to add extra data to the stream, such as for #26


This comment has been minimized.

Copy link

commented Oct 4, 2019

Ah, so the idea is that the "unidirectional stream ID" here could be a hard-to-guess nonce and thus knowledge of it could serve as proof to the stream server that the client was spawned either by an expected origin page or a page that collaborated with the expected origin page to learn the nonce?

That sounds reasonable.


This comment has been minimized.

Copy link

commented Oct 5, 2019

Nothing fancy like that. The stream ID is always 2. We just decided to replace our current origin mechanism with just sending the origin explicitly (just like CORS and WebSocket). It's in the editor's copy of the draft now, if you want to take a look.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants
You can’t perform that action at this time.