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

[Tobias Oberstein <[e-mail]>]

> 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