Re: Hello from Mozilla

On Sat, 18 Jul 2009, Amos Jeffries wrote:
> Ian Hickson wrote:
> > On Fri, 17 Jul 2009, Amos Jeffries wrote:
> > > Um, okay. Have a read of this alternate Spec and see if you can stil find
> > > the security hole you are woried about:
> >
> > I don't understand in what way it substantially differs from what the
> > spec says today. There are minor differences in wording, but other
> > than that, and other than the requirement that two TCP connections be
> > established to port 80 when using port 80 instead of just one, it
> > seems equivalent. Could you elaborate on what the important difference
> > you had in mind is?
>
> Two connections? no. Only one. Two METHODS of possible connection.

It seems like you are suggesting trying to send a TCP "SYN" twice in
certain cases. That's what I mean by two connections.

> 1) CONNECT and HTTP Upgrade are optional, and independent. One may be used or
> the other. They may be both tried in any order.

That doesn't sound specific enough to get interoperable behaviour. It
seems like we'd want to define exactly what the sequence of events should
be (as the draft does now, for instance), rather than leaving it open.

> 2) Specific mention is made that these are for failover use ONLY after port 81
> and 815 have both already been tried and cannot be used.

If you want to first try port 81, then try port 815, then try another
port, then we are talking about at least _three_ connection attempts, each
of which could have multisecond latency. That simply isn't workable.

> 3) The specific order of bytes is not mentioned _anywhere_ in the new text.

That seems like a problem, not a benefit.

> 4) The order of headers _received_ is not mentioned past the 101 / 4xx /5xx
> line. HTTP varies order in-transit.

I'd feel much more confident with more than one line's worth of handshake.

> 5) Specific mention is made to ignore non-understood headers added randomly by
> intermediaries.

So long as that happens after the handshake, that's ok, but we can't allow
that inside the handshake, it would allow for smuggling data through,
effectively faking the handshake with unexpecting servers. (I also don't
really understand the point. If there are intermediaries adding data, then
frankly we probably _do_ want the connection to fail.)

> 6) Specific mention is made to drop random extra body data sent with headers
> or request and reply and how to handle it. Fixing that data-feeding issue you
> worry about.

I don't understand what you mean here.

> 7) Most importantly. The WebSocket handshake is not involved in this
> section. It happens after the Upgrade shift / CONNECT tunnel / port-81
> TC link has succeeded. Not mid-way though the HTTP Upgrade processes.

The handshake absolutely must be the very first byte, otherwise you can
just trick the remote end into sending back the appropriate bytes for the
handshake half-way through what it thinks is an unrelated part of the
connection, depending on what the remote end's protocol is.

> Between them these differences convert your section 3.1 from a detailed
> byte-level handshake, very flaky in any non-direct port-80 link, to an
> HTTP-level handshake which can be relayed or handled properly by
> existing MITM and Surrogates.

We don't want WebSocket relayed by MITM proxies. That's not compatible
with HTTP as far as I can tell.

(I really don't understand what is "flaky" about a fixed set of bytes.)

> HTTP clients and servers need very little change to operate with this as
> well and can leverage their broad base of HTTP code to process the
> headers properly and safely to the required end.
>
> As Henrik pointed out, there are HTTP things I've overlooked in the quick
> re-write. But their addition is minor editing touchups.
> HTTP Keep-Alive stuff may also be needed to encourage the WebSocket link to
> stay up long-term use for the handshake and data frames.

I don't understand why HTTP would be involved here at all. The only reason
we have any kind of HTTP-like handshake is to allow for port sharing, not
to allow any kind of relaying. I wouldn't expect or desire HTTP proxies to
know anything about WebSocket. If any proxies are going to be used, they
should be protocol-agnostic proxies like SOCKS.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'