Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-13.txt

Tobias Oberstein <tobias.oberstein@tavendo.de> Thu, 08 September 2011 18:18 UTC

Return-Path: <tobias.oberstein@tavendo.de>
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 07D9321F89BA for <hybi@ietfa.amsl.com>; Thu, 8 Sep 2011 11:18:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.511
X-Spam-Level:
X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id odUyQ339leB4 for <hybi@ietfa.amsl.com>; Thu, 8 Sep 2011 11:18:27 -0700 (PDT)
Received: from EXHUB020-2.exch020.serverdata.net (exhub020-2.exch020.serverdata.net [206.225.164.29]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8B421F8804 for <hybi@ietf.org>; Thu, 8 Sep 2011 11:18:26 -0700 (PDT)
Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-2.exch020.serverdata.net ([206.225.164.29]) with mapi; Thu, 8 Sep 2011 11:20:17 -0700
From: Tobias Oberstein <tobias.oberstein@tavendo.de>
To: John Tamplin <jat@google.com>
Date: Thu, 08 Sep 2011 11:18:55 -0700
Thread-Topic: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-13.txt
Thread-Index: AcxuT3as9na7dKerSiqhijs5L6y0swAApGkA
Message-ID: <634914A010D0B943A035D226786325D422C0F6DCD2@EXVMBX020-12.exch020.serverdata.net>
References: <20110831184207.1514.64093.idtracker@ietfa.amsl.com> <0fc901cc6878$1681eec0$0a00a8c0@Venus> <CAH9hSJb2rH+fX0AnekYxsEkHKzb15aHrg_hDQw1baWLiWBF-3w@mail.gmail.com> <17b501cc6d31$3016d6d0$0a00a8c0@Venus> <CAH9hSJYhLpcXrOtS-nzLt2YW9QbngEsfdcNF+0TadyVA6rrK1A@mail.gmail.com> <17ef01cc6d39$3575ae50$0a00a8c0@Venus> <20110907085128.GA19144@1wt.eu> <CAH9hSJYXZ285L_+eJh6VUVCAg4D+u=vQbcjVOA4RMsJSbcHqiw@mail.gmail.com> <CABLsOLBKgnTFga821t2AZ1dXobTsfMb5v8CTJhm_Nr8WMkonaA@mail.gmail.com> <53451FDB-77F7-42A1-8D16-05094C35AB5D@bbn.com> <4E68E9F6.6030901@stpeter.im> <634914A010D0B943A035D226786325D422C0F6DBF7@EXVMBX020-12.exch020.serverdata.net> <CABLsOLAw=ru059x7p2EWnye6ssVQGAvrzBB9Y5mNyo9Ez_ae6A@mail.gmail.com> <634914A010D0B943A035D226786325D422C0F6DC2B@EXVMBX020-12.exch020.serverdata.net> <CABLsOLDiGZqPFfg=qfa2MSZzPq6RdCeWFZ5uHt00L8OnSxc5AQ@mail.gmail.com>
In-Reply-To: <CABLsOLDiGZqPFfg=qfa2MSZzPq6RdCeWFZ5uHt00L8OnSxc5AQ@mail.gmail.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: de-DE, en-US
Content-Type: multipart/alternative; boundary="_000_634914A010D0B943A035D226786325D422C0F6DCD2EXVMBX02012ex_"
MIME-Version: 1.0
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-13.txt
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: Thu, 08 Sep 2011 18:18:28 -0000

I think we've talked past one another: yes, in the browser, JS can't tamper with the masking,
by being restricted to do so.

What I meant was non-browser clients using a WS implementation that have an option
to "fake masking": turn on mask bit, insert mask, but don't actually mask.

That would only work if the server peer knows that masking is fake, and likely only
for binary messages. For example announcing: subprotocol "fakemask-safecpu"

An for that case: the presence of a mask (the 4 octets) plus mask bit set is not sufficient
for an intermediary to know that the payload is actually masked and detect the faking.

A masking scheme that i.e. requires the mask to be the first 4 bytes of the SHA1 computed
over the frame payload would have made that impossible, and intermediaries could actually
proof that frames are really masked. Unmask, recompute SHA1 over frame payload and
compare to mask. Very hard to fake. But I'm certainly NOT advocating anything like that.
It would break streaming i.e. - I'm fine with the current stuff.


Von: John Tamplin [mailto:jat@google.com]
Gesendet: Donnerstag, 8. September 2011 19:48
An: Tobias Oberstein
Cc: Peter Saint-Andre; Richard L. Barnes; hybi@ietf.org
Betreff: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-13.txt

On Thu, Sep 8, 2011 at 1:04 PM, Tobias Oberstein <tobias.oberstein@tavendo.de<mailto:tobias.oberstein@tavendo.de>> wrote:
A client can just send frames with mask bit set, a random mask, but don't actually mask (XOR) the payload.

The intermediary can check for mask bit set, unmask the payload using the random mask,
and then?

When a client send white noise as payload, XORing the white noise with any mask will not
change the statistics of the result vs the original.

Same for any sane encryption, which looks like white noise after encryption, and will look
like white noise after XOR with _any_ mask

How can an intermediary proof that payload is really masked?

It knows the payload is really masked because a mask was present.  Obviously, it can't know whether the payload was chosen to produce some value after masking (any more than it could know why any particular payload was chosen), but the browsers enforce that by not letting the JS code control the key.

--
John A. Tamplin
Software Engineer (GWT), Google