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

[Takeshi Yoshino <[e-mail]>]

Considering CRIME attack, we have a note in the current multiplexing spec
saying that history based compression should not be used over chunks
containing handshake and ones containing script generated data keeping
compression context.

E.g.
Sec-WebSocket-Extensions: permessage-deflate, mux
is allowed but
Sec-WebSocket-Extensions: mux, permessage-deflate
is prohibited.

I listed CRIME just as an example of security consideration around
multiplexing. For now, it's already addressed in the mux spec.


On Tue, Jun 4, 2013 at 3:12 AM, Roberto Peon <[e-mail]> wrote:

> Well, more precisely, the compression context must be shared between
> material sourced by the attacker and also for the purpose of using the
> site, and the context must be probe-able in some reasonable amount of time.
> A gzip context which was reused between messages would be a no-no, for
> instance. Another compression context (which makes probing difficult) might
> be acceptable.
>
> -=R
>
>
> On Fri, May 31, 2013 at 1:27 AM, Tobias Oberstein <
> [e-mail]> wrote:
>
>>  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.
>>>
>>
>> Does above refer to the general requirement for CRIME: the attacker must
>> be able to inject data into the source material before it is compressed and
>> then encrypted?
>>
>> If so, how would that be possible with WebSocket and the proposed
>> WebSocket per-message compression?
>>
>>
>> random thoughts:
>>
>> a)
>> permessage-deflate only compresses WS data messages, not control frames.
>>
>> So the attacker would need to inject data into the app-level payload.
>>
>> The only way to send app-level payload in browsers if via the JavaScript
>> WebSocket API (socket.send()).
>>
>> So the attacker would need to somehow modify this JS code. However, the
>> origin of the JS running is (at least with browsers) sent during the WS
>> opening handshake as a HTTP header, and a WS server can check and decline
>> an incoming connection.
>>
>> b)
>> With WS HTTP headers are only sent _once_: during the initial WS opening
>> handshake, and by the client to the server.
>>
>> CRIME requires repeated injection of attacker data.
>>
>> More so: permessage-deflate does not touch the opening handshake, which
>> remains uncompressed.
>>
>> Side Q: Do browsers reuse an established TLS/TCP connection for multiple
>> WS connections?
>>
>> /Tobias
>>
>>
>