Re: [hybi] RFC 6455 Client-Server Masking

Brian McKelvey <theturtle32@gmail.com> Mon, 28 January 2013 01:26 UTC

Return-Path: <theturtle32@gmail.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B42921F86CA for <hybi@ietfa.amsl.com>; Sun, 27 Jan 2013 17:26:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.203
X-Spam-Level:
X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u15wtLgdVGju for <hybi@ietfa.amsl.com>; Sun, 27 Jan 2013 17:26:11 -0800 (PST)
Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by ietfa.amsl.com (Postfix) with ESMTP id BD5A521F8573 for <hybi@ietf.org>; Sun, 27 Jan 2013 17:26:11 -0800 (PST)
Received: by mail-pa0-f50.google.com with SMTP id hz10so1196297pad.37 for <hybi@ietf.org>; Sun, 27 Jan 2013 17:26:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=p3ykf3Rs5/DXVpsSAPv7JCBvMsiM2yujRkZ1ikL/fTc=; b=h3KXrvdTnktlRlu5myUaI/9epx8FxQPRG8ALiw4OsSfv0mS8B1KMXil9nZxAZuOY+6 X66OVVUoJgRbokQoSNEzZyBBHOnOUTP1njUm7vmWcWYNZdTT1Tupbr07iRVTZLiDssjL FSl1smbAnYWh0X0MyS39j0U74269ChApLZnUOhaHV3cdWKPLbwTXv5k0mb3oUZqClFgp CI9ybEK5a07wP1LAj+1JDkG7uv36uoDPqyi3ZgGLeWIT+w4+s63iWlI/qS1+I/yDRdMJ TpPsFkLVA2/jRKKVw5O7MfJ4KL2NVC65iPzt5LwetYRsVFhhvFbjDEhHveRYhxHhl6On 7wPw==
X-Received: by 10.66.74.98 with SMTP id s2mr31907264pav.64.1359336371518; Sun, 27 Jan 2013 17:26:11 -0800 (PST)
Received: from [192.168.0.101] (75-142-117-193.static.mtpk.ca.charter.com. [75.142.117.193]) by mx.google.com with ESMTPS id kp4sm5222597pbc.52.2013.01.27.17.26.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 27 Jan 2013 17:26:10 -0800 (PST)
References: <5105BF2D.50104@googlemail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <5105BF2D.50104@googlemail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-Id: <C999964D-E0F6-45A7-A0A1-AE36AEAF4315@gmail.com>
X-Mailer: iPhone Mail (10A525)
From: Brian McKelvey <theturtle32@gmail.com>
Date: Sun, 27 Jan 2013 17:26:07 -0800
To: "denis.m.f.mcmahon@googlemail.com" <denis.m.f.mcmahon@googlemail.com>
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] RFC 6455 Client-Server Masking
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 28 Jan 2013 01:26:12 -0000

The purpose of the masking has nothing to do with preventing eavesdropping or interception.  It's meant to prevent malicious javascript running in a web browser from connecting to arbitrary non-websocket services, or from tricking http-unaware proxies into doing the attacker's bidding, caching malicious data, etc.

It's about preventing browsers from initiating attacks against unsuspecting services, not about preventing eavesdropping or securing the privacy of data in transit.  The use of TLS with WebSockets is required for that.

Brian

Sent from my iPhone

On Jan 27, 2013, at 3:58 PM, Denis McMahon <denis.m.f.mcmahon@googlemail.com> wrote:

> The unpredictability of the masking key is essential to prevent authors
> of malicious applications from selecting the bytes that appear on the wire.
> 
> From this statement, I assume that the purpose of masking is "to prevent
> authors of malicious applications from selecting the bytes that appear
> on the wire."
> 
> -= However =-
> 
> The masking key is transmitted as part of the packet, and appears as 4
> bytes ABCD. This is like sending data inside a locked casket for
> security, WITH THE KEY SAFELY TIED TO THE CASKET!
> 
> It follows from the protocol description that to detect any arbitrary
> sequence of n bytes in length, it is merely necessary to determine the
> four possible bit sequences that those bytes might represent, and
> monitor for all four of those bit sequences.
> 
> The masking sequence for any N bytes of data will be one of four
> sequences, based on the mask bytes ABCD:
> 
> 012345678.....n
> ABCDABCDA......
> BCDABCDAB......
> CDABCDABC......
> DABCDABCD......
> 
> Given any sequence b1 ... bn which the attacker wishes to detect, the
> attacker simply has to combine, for each frame, b1 ... bn with each of
> the 4 possible sequences of n bytes in length of masking bytes, and
> listen for all 4 sequences. Computationally this is a trivial exercise!
> 
> This mechanism does nothing to significantly increase the difficulty of
> a malicious application listening to the bytes on the wire with the
> intention of detecting specific patterns.
> 
> It would be much better if the protocol dropped the masking concept,
> stated that it makes no attempt to protect data from eavesdropping or
> interception, and made the recommendation that if data security is
> desired, then appropriate transport layer security eg RFC 5246 TLS1.2 /
> RFC 6101 SSL3.0 should be employed.
> 
> Denis McMahon
> 
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi