Re: [hybi] Masking only Payload/Extension Data

Andy Green <> Thu, 10 March 2011 15:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 772053A6B0E for <>; Thu, 10 Mar 2011 07:35:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.587
X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uA79Qij9X9+b for <>; Thu, 10 Mar 2011 07:35:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 11E093A6B0B for <>; Thu, 10 Mar 2011 07:35:13 -0800 (PST)
Received: by wwa36 with SMTP id 36so1449744wwa.13 for <>; Thu, 10 Mar 2011 07:36:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KUZnV2tx00ZfmC9a/Y1YME6VMzuv4imH86znloRSc6g=; b=Bum6K4Ud9qb7W8vY8CdoDiu5zMfIFwWV2H9kMruDMCFhkT3YNUmsZNC7d0O7EveS5l RolzzZ6iamfXxesxlcC1ebt6YmWBet5ivMTelkWrgRndI6L1nwVnnF9PQ8w+u4W7Stj+ mLquU8ZiK3bvMTkEWEtlgHR9Ob5qo+N9QHCLs=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=NkViIEMptwjc0u7GUIUOm9bhQYZMzAqEWvtf/FCvDwDD22xioR6JbWLkKZTOntLtgk jIvEZj7dXM4YBM0GFrIiC6k5bkcHVPmDtQPlKWj7ZQJFojRpHCf7R3HrBI9vbbZ0ffFb kS++bvyPyfsTHjyJUoOcjDcKCdkRU54Ld+TSU=
Received: by with SMTP id eb11mr7227699wbb.120.1299771391251; Thu, 10 Mar 2011 07:36:31 -0800 (PST)
Received: from ( []) by with ESMTPS id w25sm2521136wbd.5.2011. (version=SSLv3 cipher=OTHER); Thu, 10 Mar 2011 07:36:30 -0800 (PST)
Sender: Andy Green <>
Message-ID: <>
Date: Thu, 10 Mar 2011 15:36:29 +0000
From: Andy Green <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110302 Fedora/3.1.8-3.fc16 Thunderbird/3.1.8
MIME-Version: 1.0
To: "Pat McManus @Mozilla" <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Hybi <>
Subject: Re: [hybi] Masking only Payload/Extension Data
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Mar 2011 15:35:15 -0000

On 03/10/2011 03:04 PM, Somebody in the thread at some point said:

Hi -

>> I suspect most would agree that masking of everything is better than
>> stalling the protocol any longer, but if Adam is the only objector and
>> the browser folks are okay with masking only payload then perhaps we
>> should move forward with it.
> I object too. I think not masking the header gives up a minor security
> benefit for an insubstantial benefit. None of the arguments about the

It is much cleaner protocol-wise to have consistent framing and mask 
inside the extension area and allows server traffic masking to be 
selected the same way.

Once that's done, if 4-byte recirculating xor with per-frame random key 
isn't enough, and we have been told it is not "enough" before if you 
recall, then it'll be easy to upgrade the protocol to use AES masking or 
whatever without breaking the framing.

> benefits of the change have convinced me they add up to very much.

To be fair these are mainly defending the idea of masking as a whole, by 
explaining that it is cheap -->


That's not really the issue, the issue is do we really impact these 
security concerns by letting what is often just two bytes but may extend 
to ten structured bytes with opcode + length in go out unmaksed.

What in fact does your Mozilla implementation do about breaking large 
messages into CONTINUATION?

As a sort of side note, since you have been supporting protecting these 
alleged vulnerable proxies, do you have any effort or interest in any 
effort to actively detect and identify them, maybe a fuzzing tool for 
content?  It's curious there's so much handwringing about these alleged 
vulnerable intermediaries but actually I didn't see anyone give a toss 
about finding them until now.