Re: [hybi] [Technical Errata Reported] RFC6455 (3215)

John Tamplin <jat@google.com> Mon, 07 May 2012 03:01 UTC

Return-Path: <jat@google.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 C249221F8464 for <hybi@ietfa.amsl.com>; Sun, 6 May 2012 20:01:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.916
X-Spam-Level:
X-Spam-Status: No, score=-102.916 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 O4MDlJr6aLXq for <hybi@ietfa.amsl.com>; Sun, 6 May 2012 20:01:04 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1333121F8441 for <hybi@ietf.org>; Sun, 6 May 2012 20:01:03 -0700 (PDT)
Received: by yenq13 with SMTP id q13so67339yen.31 for <hybi@ietf.org>; Sun, 06 May 2012 20:01:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=pCq9CFUdPgKeBW9X0q6ilp5zPqpUw1FRCKtu6jRRsUY=; b=NCJ0n79ALTNzn73vS8Wb3UFbg01jv0kSYdtYutCY/tjyii2ttp5meaSqKcTMXfeWBb uAqElHhEXMPwDMCD0hV8HpybExH9mlh8xrNXiX2NQIMnoBbeA38pgkdJ3/kCBxbwZNW0 00G9A6v0woBvUGICwomK1HaDt6EJQTPtDAq6llggLbo4KTGcI4h0XENAXWJl34UpymPH jhe3vOxZQP3RyeXSGMefPwMBto3sWSViYbY5PU2+4PICZlVKkXvRKn1un2Vat5ExX0Zx mGUBlqg1SolH1yZrZbJ4B/ApZSybTIQhbdlkLXIknNnfMQOhyzSgdsC5N6oJf7exGUY5 +7xw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=pCq9CFUdPgKeBW9X0q6ilp5zPqpUw1FRCKtu6jRRsUY=; b=Z3g5v260x4Zm13O9enxKgb/8pvu58l4fyfExG9pIhiNXBuQctzGfrw0wTJLgZ5pLDH JJ3upD6u61yIYt11+l4PVtFYxHc171k+sUwBR9AY2BP7NKcgGZIBcYr89WNvjbhnUn7g 41qdQPCNujEMm5TrZBwqIgkzTVX1Qc0ucBSWxSwzLxxXdLnjkATeG/BYRMp7nscD69nb UffSgHl++d8DkJlCZG02RjI/WTj0I60j3wCL0fx4PjypbJDzSVg3hYk7dL23m/pRPEwp ahqlRXzAZC9Z71KNYR6uwQloltyw2KwBiE6cVxvQZaLKAxKEfX3v3JOBUAdexRwukIkq UZYg==
Received: by 10.43.131.201 with SMTP id hr9mr7440331icc.8.1336359663317; Sun, 06 May 2012 20:01:03 -0700 (PDT)
Received: by 10.43.131.201 with SMTP id hr9mr7440325icc.8.1336359663203; Sun, 06 May 2012 20:01:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.9.169 with HTTP; Sun, 6 May 2012 20:00:42 -0700 (PDT)
In-Reply-To: <20120507003008.A70F2B1E002@rfc-editor.org>
References: <20120507003008.A70F2B1E002@rfc-editor.org>
From: John Tamplin <jat@google.com>
Date: Sun, 06 May 2012 23:00:42 -0400
Message-ID: <CABLsOLC-UrivyU-U-od+k3EKZugv-5ZSxj+TUYjgVYsYjtmeLg@mail.gmail.com>
To: jesse.katzman@gmail.com
Content-Type: multipart/alternative; boundary="20cf307f34c804761b04bf697b69"
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQnpL6bLvZXlX5XYPTNCwrzk+NYeYcF/CcnNC9Fjgvrt1padvcngx2CxYah/n6TsL3bgcD+HfVfepcx9cPEekoiBsqh1ESQnRJVssXdlhldIm55dblD7AZUDN7tkN1AC/tzBcXJ1
Cc: hybi@ietf.org
Subject: Re: [hybi] [Technical Errata Reported] RFC6455 (3215)
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, 07 May 2012 03:01:04 -0000

On Sun, May 6, 2012 at 8:30 PM, RFC Errata System <rfc-editor@rfc-editor.org
> wrote:

> Type: Technical
> Reported by: Jesse Katzman <jesse.katzman@gmail.com>
>
> Section: 5.3
>
> Original Text
> -------------
> The unpredictability of the masking key is essential to prevent authors of
> malicious applications from selecting the bytes that appear on the wire.
>
> Corrected Text
> --------------
>
>
> Notes
> -----
> I don't see how the client-to-server masking prevents "authors of
> malicious applications from selecting the bytes that appear on the wire".
>
> Maliciously changing the contents of a message simply requires a few more
> steps than it would without masking, as far as I can tell.
>

Masking the client->server frames was heavily debated on this list for
months -- I encourage you read the archives rather than rehashing the
debate.

Basically, WebSockets is unique in that you need to protect the network
infrastructure, even if you have hostile code running in the client, full
hostile control of the server, and the only piece you can trust is the
client browser.  By having the browser generate a random mask for each
frame, the hostile client code cannot choose the byte patterns that appear
on the wire and use that to attack vulnerable network infrastructure.

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