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

[Tobias Oberstein <[e-mail]>]

Am 30.05.2013 20:28, schrieb Roberto Peon:
> Different schemas have nothing to do with the CRIME attack.
> A pure HTTPS or WSS scheme could still be attacked with CRIME, with its
> success depending on the way the compression mechanism works.
> With the current HTTP/2 proposals it would be pretty difficult to attack
> using the techniques in the CRIME attack.
>
> The way CRIME works is to have a 3rd party include links to the
> site-to-attack. Thus it doesn't matter if the schemes are http, https,
> ws, wss, whatever.
> So, a restriction against muxing ws and wss together makes no sense as
> it provides no security benefit for CRIME.

What about the other issues listed?

Example:

An app first connect to a ws: address. Then the app opens a 2nd 
connection over wss: to the same target (IP:port) sending some sensitive 
information (either in cookies or in payload) relying on the presumed 
privacy/encryption provided by wss:.

An implementation of MUX might run the 2nd wss: connection as a logical 
WS connection over an _unencrypted_ physical ws: that was established in 
the first place upon the app opening the 1st ws: connection.

So at least the implementation must not mux logical wss: over physical ws:.

Transporting logical ws: over physical wss: seems less problematic.


> -=R
>
>
> On Thu, May 30, 2013 at 1:29 AM, Tobias Oberstein
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     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 <http://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 <http://domain.com>, domain2.com
>     <http://domain2.com> and sub1.domain.com <http://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
>
>
>     _______________________________________________
>     hybi mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/hybi
>
>