Re: [hybi] IESG note?, was: Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard

"Richard L. Barnes" <> Tue, 06 September 2011 21:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26F6521F8EE7; Tue, 6 Sep 2011 14:34:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.547
X-Spam-Status: No, score=-106.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yImODBPsEAY8; Tue, 6 Sep 2011 14:34:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 290DA21F8EE6; Tue, 6 Sep 2011 14:34:20 -0700 (PDT)
Received: from ([]:63826) by with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <>) id 1R13JL-0003x9-CV; Tue, 06 Sep 2011 17:36:03 -0400
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <>
In-Reply-To: <>
Date: Tue, 6 Sep 2011 17:36:01 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Stephen Farrell <>
X-Mailer: Apple Mail (2.1084)
Cc: Server-Initiated HTTP <>,, "Roy T. Fielding" <>,
Subject: Re: [hybi] IESG note?, was: Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard
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, 06 Sep 2011 21:34:21 -0000

> On 09/06/2011 06:57 PM, Richard L. Barnes wrote:
>> IMO, this is a pretty strong argument against masking, given how low the observed rate of buggy intermediaries is (~0.0017%) and how high the observed rate of malware propagation is.
> I'm not sure what you're comparing there. Can you elaborate?

Sorry, should have provided references.  The observed rate of cache poisoning vulnerability is from the "Talking to Yourself for Fun and Profit" paper.  They did an empirical study (using an ad buy) of several variants of the WebSocket protocol.  They found 8 users vulnerable out of around 54,526 tested. So I actually had my math a bit wrong, the prevalence is more like 0.015%.

It's worth noting, though, that their experiment used an older version of the protocol (-03 at the latest), and is not compliant with whichever version they used.  In particular, they omit the data framing header.  Since these octets seem unlikely to increase the probability of a proxy accepting a poisoning request, I would regard their number as an upper bound on the prevalence of buggy proxies.

Another interesting finding in that paper was that there were no observed instances of a CONNECT-based variant of the protocol successfully poisoning proxies (on the same sample set of ~54k users).  This might lead one to think that the problem that masking solves could also be avoided by using HTTP differently.  I think that this option was discussed in the WG and decided against, but I don't know why. 

> In fact, I'm not sure I get the malware argument. Malware
> authors are also free to obfuscate or mask their stuff,
> when both sides of the conversation but not the intermediaries
> are controlled as would be the case here. Or maybe I'm
> missing something?

It's a question of how many layers of obfuscation the firewall has to manage.  Malware scanners have to deal with polymorphism already today, and there are lots of approaches, so that's not really an is.  Masking is a layer on top that the firewall would have to unwrap.  Just as with 6to4, in principle, masking is just an annoyance, another thing to decapsulate.  In practice, firewalls have not kept up with these things, so requiring masking on WebSockets is likely to create a reasonably long-lived channel for circumventing firewalls.

> I personally think the masking thing is pretty ugly. But I
> have to (reluctantly) admit I think it does what its
> supposed to do. At this stage I think it comes down to
> either doing the masking or not using port 80.

I'm sort of of the same feeling.  I don't disagree that masking solves the problem it sets out to.  The question is whether there are other ways to solve the problem that are simpler, with fewer side effects.