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

[Roberto Peon <[e-mail]>]

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