Re: [hybi] Call for interest: multiplexing dedicated for WebSocket

[Tobias Oberstein <[e-mail]>]

Am 30.05.2013 09:28, schrieb Takeshi Yoshino:
> On Thu, May 30, 2013 at 1:12 PM, Adam Rice <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>         So d) - f) cannot be multiplexed over the same physical WS as
>         a) - c)?
>
>         Or can an implementation just "silently" transport a)-c) also
>         over wss, and hence multiplex all of a) - f) over 1 physical WS?
>
>
>     The handshake does not currently include the schema, so there
>     would be no way to communicate to the server that a)-c) were
>     supposed to be ws:, not wss:.
>
>
> Right. I missed that point.
>
>     Even if this was amended, both client and server would have to be
>     careful that no ambient authority leaked from the wss: channels to
>     the ws: channels. For example: the client would have to be careful
>     not to send "secure" cookies with the ws: handshakes, and the
>     server would have to be careful not to apply any authority
>     contained in a client TLS certificate to the ws: logical channels.
>
>     For this reason, I think it would be easiest not to attempt to
>     multiplex ws: and wss: onto a single TCP/IP connection.
>
>
> Compression contexts, etc. also need to be isolated carefully to 
> protect it from attack like CRIME.

I also agree with Adam. To summarize, given the possible "issues" of

- client cert based auth
- "secure" cookies / ambient authority
- compression contexts / CRIME

(plus complexities like: what if an app opens ws://domain.com, and then 
_later_ opens wss://domain.com? Upgrade to TLS not possible anymore .. 
cannot TLS handshake in the middle of an already established non-TLS TCP 
where some traffic already traveled .. the WS handshake at least.)

I think it would be good to include explicit text into the MUX draft, e.g.

"""
An implementation MUST NOT multiplex multiple logical channels to 
WebSocket addresses with different schemes (ws: versus wss:) on a single 
physical WebSocket connection.

For example, two WebSocket connections to ws://domain.com and 
wss://domain.com must not be shared on a single physical WebSocket 
connection to domain.com.
"""

I also think it would be helpful to include explicit text describing 
what WebSocket addresses are eligible for sharing, e.g.

"""
An implementation MAY multiplex multiple logical channels to different 
WebSocket addresses if and only if the WebSocket addresses share the 
same WebSocket scheme, the hostname resolves to the same IP address and 
the same port.

For example, connections to all of the following WebSocket addresses may 
be multiplexed over a single physical WebSocket connection (assum 
domain.com, domain2.com and sub1.domain.com all resolve to the same IP 
address):

ws://domain.com
ws://domain.com:80
ws://domain.com/foo
ws://domain.com:80/foo
ws://domain.com/bar
ws://domain2.com
ws://sub1.domain.com
ws://sub1.domain.com:80
ws://sub1.domain.com:80/bar

Note: When a WS address does not specify an explicit port, the port is 
the default port for the given WS scheme (ws: = 80 and wss: = 443).
"""




/Tobias