Re: [hybi] Fwd: Gen-ART last call review of draft-ietf-hybi-thewebsocketprotocol-10

David Endicott <dendicott@gmail.com> Thu, 21 July 2011 03:44 UTC

Return-Path: <dendicott@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 B2D2811E8070 for <hybi@ietfa.amsl.com>; Wed, 20 Jul 2011 20:44:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 MJEE1YnEsepc for <hybi@ietfa.amsl.com>; Wed, 20 Jul 2011 20:44:25 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7611F0C35 for <hybi@ietf.org>; Wed, 20 Jul 2011 20:44:24 -0700 (PDT)
Received: by wwe5 with SMTP id 5so568401wwe.13 for <hybi@ietf.org>; Wed, 20 Jul 2011 20:44:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qvgHQxNX7xzloI9krRvLqcsm/TWHvB80IpBcZ4yyPKw=; b=mG9EMUOITBEBaUNWgQSBMSKfpSQTzVzGM1u3f8863aw/jiBjOCbzM8skL16gXEydzv 5t8CZnkXVYGQzBA/8rilGfnd9qK/Zxh1FMKHCij0DHYnyAHR2GNjtvUJdSoGGcbIYbVl CdfAbn/CpBo4D7XW8k8ozB25Prbf2iahqs+kk=
MIME-Version: 1.0
Received: by 10.217.6.82 with SMTP id x60mr381956wes.18.1311219862997; Wed, 20 Jul 2011 20:44:22 -0700 (PDT)
Received: by 10.216.39.197 with HTTP; Wed, 20 Jul 2011 20:44:22 -0700 (PDT)
In-Reply-To: <CABLsOLCy3xAtXavSGc1mJA18Yhh7gZoaVX9Rg07Dyka1sNx0Tw@mail.gmail.com>
References: <4E2792EB.2070408@stpeter.im> <CABLsOLCy3xAtXavSGc1mJA18Yhh7gZoaVX9Rg07Dyka1sNx0Tw@mail.gmail.com>
Date: Wed, 20 Jul 2011 23:44:22 -0400
Message-ID: <CAP992=ELXXfOevQB7vPP+5-X2D7uPLxmHvHPuNbs36PQsN0aEw@mail.gmail.com>
From: David Endicott <dendicott@gmail.com>
To: John Tamplin <jat@google.com>
Content-Type: multipart/alternative; boundary=20cf301fb94d28093b04a88c2a2c
Cc: rbarnes@bbn.com, "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] Fwd: Gen-ART last call review of draft-ietf-hybi-thewebsocketprotocol-10
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, 21 Jul 2011 03:44:26 -0000

Speaking as an unauthorized spokesperson for dissenters....


On Wed, Jul 20, 2011 at 11:23 PM, John Tamplin <jat@google.com> wrote:

> On Wed, Jul 20, 2011 at 10:46 PM, Peter Saint-Andre <stpeter@stpeter.im>
> wrote:
> > From: Richard L. Barnes <rbarnes@bbn.com>
> > Document: draft-ietf-hybi-thewebsocketprotocol-10.txt
> > Reviewer: Richard Barnes
> > Review Date: 19 July 2011
> >
> > Summary:
> > Not ready.
> >
> > Major issues:
> >
> > [Huge buffers]
> > The frame length can be 7, 16, or 64 bits long.  Since the client is
> expected to buffer data until the end of a frame,
> > this is asking clients to buffer 128 B, 64 KB, or 16 EB.  If it were 32
> bits, the max would be 4 MB.  Why not just
> > make this a 32-bit fixed length field?
>
> It is a compromise to get everyone to agree.  There were several
> requirements different groups were interested in:

As there were holdouts on both the side of wanting small headers for
> small frames and wanting to send large messages without having to
> fragment, this compromise was necessary to make progress.
>

It was my perception that in general people were agreed on the obvious
choices (minimize overhead, be flexible), nobody had the energy/interest to
challenge the ridiculous, as we'd all just ignore it or crash in our real
world implementations.


>
>> > [Why is masking necessary?]
>
> There was a very long, contentious discussion about this based on
> security research that found transparent proxies could be fooled into
>

I've not seen this research.

believing the content following the WebSocket handshake was HTTP,
> allowing poisoning a transparent cache -- imagine if an attacker could
> replace the contents of www.google.com/ga.js on some cache serving
> many users, basically it is a wildcard XSS for users of those caches.
> There was no attack demonstrated using WebSocket framing, but it was
>

Ah.


> demonstrated using just the WS handshake followed by user-controlled
> data.
>
> The scenario here is....


Giving me qualms of plausibility.  But I would challenge instead that this
is a fault of the intermediaries and not our problem.


>
> > [Why only client-to-server masking?]
> > Why isn't masking required on server-to-client frames?
>
> In the attack scenario, the server is under complete control of the
> attacker and can send any bytes it chooses anyway.
>

The dissenting consensus was that half an ass of security was not a donkey
we wanted to hitch our cart to.


>
> > [Unlimited buffering with fragmentation]
> > Much like with the frame length issue above, the fragmentation mechanism
> here seems like it imposes a
> > heavy burden on the receive side.  Since the receiving client is supposed
> to buffer data until the end of a
> > frame, it seems like fragmentation could be used to cause a receiving
> client to buffer a frame of indefinite size.
>
> Obviously, an implementation will have to have a maximum size message
> that it can support.  In the spec as written, the only recourse when
> this size is exceed is to terminate the connection (perhaps retrying
> sending smaller messages).  There have been some proposals to allow
> each side to state their maximum frame and/or message sizes in the
> handshake, but there hasn't been agreement to put them in the spec.
>

Allowing streaming is a laudable goal, but WS comes out of the gate as a
framing protocol.


>
> > [Why not plain sockets?]
> > The introduction makes clear why this protocol is needed instead of HTTP,
> but not why this protocol
> > improves over providing a plain socket interface.  Presumably this is
> because the HTTP header provides
> > a space where the browser can inject trusted information?
>
> The browser is executing code on behalf of a potential attacker, and
> would not give access to raw TCP sockets to such code as that would
> allow circumvention of many protections, such as scanning machines
> behind a corporate firewall, for example.  If you mean just opening a
> socket subject to the same origin restrictions, you would have to have
> a special handshake to validate those restrictions, and you need some
> framing to delineate messages since TCP is just a stream of bytes and
> the API is message-oriented.  If you do those things, then you have
> essentially WebSockets (of course you could solve the same problems in
> different ways, but it is the same class of solution).
>

I don't believe anyone suggested raw TCP sockets.    In John's example, he
is referring strictly to browser clients.   As a programmer guy, I can write
a websocket client in whatever language I want and pretend to be a websocket
as polite or malicious as I want.

I believe there are some who were hoping websockets would be a lightweight
transport protocol (a la TCP) that could be made available in a browser with
the understanding that the browser implementation of such a client would
apply appropriate security models.     Some of us are worried that the
design has suffered from concerns outside it's problem domain.



>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>