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

[Roberto Peon <[e-mail]>]

inline


On Thu, May 30, 2013 at 11:44 AM, Tobias Oberstein <
[e-mail]> wrote:

> 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:.
>

Agreed. That would invalidate the security guarantee of wss.


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

Yup!
-=R


>
>
>  -=R
>>
>>
>> On Thu, May 30, 2013 at 1:29 AM, Tobias Oberstein
>> <[e-mail] <mailto:tobias.oberstein@**tavendo.de<[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<https://www.ietf.org/mailman/listinfo/hybi>
>>
>>
>>
>