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

[David Endicott <[e-mail]>]

Speaking as an unauthorized spokesperson for dissenters....


On Wed, Jul 20, 2011 at 11:23 PM, John Tamplin <[e-mail]> wrote:

> On Wed, Jul 20, 2011 at 10:46 PM, Peter Saint-Andre <[e-mail]>
> wrote:
> > From: Richard L. Barnes <[e-mail]>
> > 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>