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

David Endicott <> Thu, 21 July 2011 03:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B2D2811E8070 for <>; Wed, 20 Jul 2011 20:44:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.598
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MJEE1YnEsepc for <>; Wed, 20 Jul 2011 20:44:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1B7611F0C35 for <>; Wed, 20 Jul 2011 20:44:24 -0700 (PDT)
Received: by wwe5 with SMTP id 5so568401wwe.13 for <>; Wed, 20 Jul 2011 20:44:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id x60mr381956wes.18.1311219862997; Wed, 20 Jul 2011 20:44:22 -0700 (PDT)
Received: by with HTTP; Wed, 20 Jul 2011 20:44:22 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Wed, 20 Jul 2011 23:44:22 -0400
Message-ID: <>
From: David Endicott <>
To: John Tamplin <>
Content-Type: multipart/alternative; boundary=20cf301fb94d28093b04a88c2a2c
Cc:, "" <>
Subject: Re: [hybi] Fwd: Gen-ART last call review of draft-ietf-hybi-thewebsocketprotocol-10
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> wrote:

> On Wed, Jul 20, 2011 at 10:46 PM, Peter Saint-Andre <>
> wrote:
> > From: Richard L. Barnes <>
> > 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 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


> 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