Re: [hybi] deflate-stream and masking

Bruce Atherton <> Tue, 21 June 2011 21:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6EF1811E80CA for <>; Tue, 21 Jun 2011 14:41:31 -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 6Pw1z12r6-QD for <>; Tue, 21 Jun 2011 14:41:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4936F11E80B7 for <>; Tue, 21 Jun 2011 14:41:30 -0700 (PDT)
Received: from [] (helo=[]) by with esmtpa (Exim 4.69) (envelope-from <>) id 1QZ8hM-0004Gn-UD; Tue, 21 Jun 2011 14:41:28 -0700
Message-ID: <>
Date: Tue, 21 Jun 2011 14:41:13 -0700
From: Bruce Atherton <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: Greg Wilkins <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
Cc: Hybi <>
Subject: Re: [hybi] deflate-stream and masking
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: Tue, 21 Jun 2011 21:41:32 -0000

Although I agree with you that deflate-stream is a bad idea and 
recognize that the decision to include it was made before it had been 
determined that masking applies only to payload data (so deflate-stream 
has to be done on masked data), I think it might be difficult to get 
agreement to remove it as a known extension in the spec at this point.

But just because it is a known extension does not mean it needs to be 
implemented. My suggestion is that everyone that thinks it is a bad idea 
should remove deflate-stream from their implementations and add in 
deflate-frame. So long as deflate-frame is available I don't imagine 
there will be a groundswell of consumer desire for the far less useful 

On 19/06/2011 11:33 PM, Greg Wilkins wrote:
> As part of my continuing campaign against including deflate-stream in
> the specification as a standard extension, I did a quick test of how
> well it works when applied to masked frames.
> I took a days worth of traffic from an IRC channel and wrapped it up
> as JSON messages sent as websocket frames.
> There were 487 message that looked like:
>       {channel:"#webtide", username:"tbecker", text:"joakime: jenkins
> had issues pulling from github a couple of times  last week"}
> As an unmasked WS stream, it was 50675 bytes, and as a masked stream
> is was 52623 bytes.
> I then compressed both these streams with gzip and got 13306 bytes for
> unmasked and 51704 bytes for the masked!!!!
> So for this very typical example, masking was sufficiently random to
> completely negate the benefits of compression.
> So the deflate-stream "extension" is:
>   + next to useless for inbound traffic
>   + breaks all the rules of what an extension can do
>   + is potentially vulnerable to injection as attackers can send
> repeated patterns that may subvert masking
>   + can be replaced by the in-frame compression extension already proposed.
>   + was inserted in the draft with little or no discussion and without
> clear consensus.
> Can I call for a straw poll of who wants to keep this extension in the spec?
> regards
> _______________________________________________
> hybi mailing list