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

[Roberto Peon <[e-mail]>]

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.
-=R


On Thu, May 30, 2013 at 1:29 AM, Tobias Oberstein <
[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]> 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
>
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>
>