[hybi] Summary of issues concerning the default masking algorithm

Bruce Atherton <bruce@callenish.com> Mon, 10 January 2011 00:14 UTC

Return-Path: <bruce@callenish.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C96873A6853 for <hybi@core3.amsl.com>; Sun, 9 Jan 2011 16:14:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.582
X-Spam-Level:
X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VRiesJw4hW4 for <hybi@core3.amsl.com>; Sun, 9 Jan 2011 16:14:51 -0800 (PST)
Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by core3.amsl.com (Postfix) with ESMTP id E8BEA3A6833 for <hybi@ietf.org>; Sun, 9 Jan 2011 16:14:51 -0800 (PST)
Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from <bruce@callenish.com>) id 1Pc5RW-0001Pl-Qz for hybi@ietf.org; Sun, 09 Jan 2011 16:17:03 -0800
Message-ID: <4D2A4FFE.6000503@callenish.com>
Date: Sun, 09 Jan 2011 16:17:02 -0800
From: Bruce Atherton <bruce@callenish.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: "hybi@ietf.org" <hybi@ietf.org>
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 - biz82.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - callenish.com
Subject: [hybi] Summary of issues concerning the default masking algorithm
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Jan 2011 00:14:52 -0000

Now that masking is officially going to be part of the protocol, I for 
one would find it useful to have all the concerns of the masking 
algorithm in one place to make it easier to reason about. I realize that 
much of this has already been discussed in various threads in all kinds 
of messages and that some (though I do not think all) consider the 
decisions on the algorithm pretty much made, but I think it would be 
easier to reason about and be certain we have consensus on them if the 
information could be gathered in a single thread.

Here is my understanding of the current state of issues around the 
masking algorithm. Please feel free to correct me or add more information.

The problems masking is intended to address are:

   1) to prevent an attacker from using a browser to initiate a 
Websocket connection to a vulnerable intermediary or non-Websocket 
server that can be exploited by sending apparent HTTP or elements of 
other protocols in a Websocket frame

and more controversially:

   2) to prevent an attacker from using a browser to open a cross-site 
scripting HTTP connection that emulates a Websocket connection

   3) to prevent potential unknown future attacks using a browser with a 
Websocket connection that can be avoided by disallowing an attacker's 
control of bits on the wire

If there are other problems masking is seen as a solution for, please 
add them. Those are the ones I am aware of.

The most basic masking suggestion I have seen is to provide a per-frame 
random mask that is sent with the frame and XORed with the contents.

The features which have been suggested to enhance this scheme that I 
know of are:

a) The client nonce should influence the mask

b) The server nonce should influence the mask

c) The mask should be kept off the wire by generating the mask using a 
shared secret
   - This means replacing the per-frame mask with a per-frame key used 
in generating the mask
   - the shared secret that has been suggested is a connection key 
generated from the client and server nonce, thus including features a and b

d) The attacker should not only be prevented from controlling the bits, 
but also the pattern of bits

Again there may be other features that have been suggested but those are 
the ones I am aware of.

I'll leave it to the advocates of each of these features to summarize 
the benefits of them that justify their costs, as I don't think I could 
do justice to them. I can make a stab at the costs, though.

For feature a, the only cost I can see is in the increase in complexity 
in generating the mask.

For feature b, there is the increase in complexity in generating the 
mask as well as the fact that you can not send a payload with the 
initial handshake from the client because you do not yet have the server 
nonce.

The principal cost of feature c that I can see is that it stops tools 
like wireshark from being able to decode streams.

The cost of feature d is increased complexity in implementation and 
added computational cost.

Feel free to add to or argue with any of these points. I've tried to 
state things as neutrally as I can.