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

Tobias Oberstein <> Fri, 31 May 2013 08:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 31FC021F901A for <>; Fri, 31 May 2013 01:27:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CQjE6v6Jb7M4 for <>; Fri, 31 May 2013 01:27:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C764321F91CB for <>; Fri, 31 May 2013 01:27:36 -0700 (PDT)
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id; Fri, 31 May 2013 01:27:35 -0700
Message-ID: <>
Date: Fri, 31 May 2013 10:27:37 +0200
From: Tobias Oberstein <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Roberto Peon <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [hybi] Call for interest: multiplexing dedicated for WebSocket
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 31 May 2013 08:27:44 -0000

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

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.

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?