[hybi] RFC 6455 Client-Server Masking

Denis McMahon <denis.m.f.mcmahon@googlemail.com> Sun, 27 January 2013 23:58 UTC

Return-Path: <denis.m.f.mcmahon@googlemail.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 9BD0B21F87F7 for <hybi@ietfa.amsl.com>; Sun, 27 Jan 2013 15:58:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.539
X-Spam-Level:
X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311]
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 eFehww6KRjKg for <hybi@ietfa.amsl.com>; Sun, 27 Jan 2013 15:58:42 -0800 (PST)
Received: from smtp.demon.co.uk (mdfmta009.mxout.tbr.inty.net [91.221.168.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8740E21F86EA for <hybi@ietf.org>; Sun, 27 Jan 2013 15:58:42 -0800 (PST)
Received: from mdfmta009.tbr.inty.net (unknown [127.0.0.1]) by mdfmta009.tbr.inty.net (Postfix) with ESMTP id D52FC38407C for <hybi@ietf.org>; Sun, 27 Jan 2013 23:58:40 +0000 (GMT)
Received: from mdfmta009.tbr.inty.net (unknown [127.0.0.1]) by mdfmta009.tbr.inty.net (Postfix) with ESMTP id B60F838406F for <hybi@ietf.org>; Sun, 27 Jan 2013 23:58:40 +0000 (GMT)
Received-SPF: neutral (mdfmta009.tbr.inty.net: 62.49.24.171 is neither permitted nor denied by domain of googlemail.com) client-ip=62.49.24.171; envelope-from=denis.m.f.mcmahon@googlemail.com; helo=[192.168.1.65];
Received: from [192.168.1.65] (unknown [62.49.24.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta009.tbr.inty.net (Postfix) with ESMTP for <hybi@ietf.org>; Sun, 27 Jan 2013 23:58:39 +0000 (GMT)
Message-ID: <5105BF2D.50104@googlemail.com>
Date: Sun, 27 Jan 2013 23:58:37 +0000
From: Denis McMahon <denis.m.f.mcmahon@googlemail.com>
Organization: Denis McMahon
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: hybi@ietf.org
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-MDF-HostID: 4
X-Mailman-Approved-At: Sun, 27 Jan 2013 16:54:03 -0800
Subject: [hybi] RFC 6455 Client-Server Masking
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: denis.m.f.mcmahon@googlemail.com
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 00:29:26 -0000

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