Re: Hello from Mozilla

On Tue, 14 Jul 2009, Alex Rousskov wrote:
> On 07/14/2009 06:01 PM, Ian Hickson wrote:
> > On Tue, 14 Jul 2009, Alex Rousskov wrote:
> >> HTTP "hard-coding" seems to be a small, albeit critical, part of
> >> WebSocket so changing it to avoid conflicts with HTTP may be possible
> >> without significant negative effects on the rest of the draft.
> >
> > The handshake is a pretty critical part of the security model of the
> > WebSocket protocol. I don't really see how we can continue to have the
> > safe handshake while allowing either the client or the server to send
> > any arbitrary string.
>
> Perhaps the WebSocket secure handshake should start _after_ the
> successful upgrade? Is not that how HTTP Upgrade was intended to be
> used?

If there are any bytes allowed from the client or the server before the
handshake starts, then it is no longer secure. The idea is to make sure
you can't smuggle though payloads from other protocols, since otherwise
you could use WebSocket to connect to services that aren't expecting it.

> > WebSocket isn't an HTTP-upgraded protocol; it's just that its
> > handshake happens to be such that it can trick HTTP servers into
> > thinking that it is. In other words, HTTP Upgrade is not the initial
> > handshake mechanism, it just looks like it is if you don't examine it
> > closely.
>
> I think I understand the intent behind the trick, but if a message looks
> like an HTTP message to the HTTP server or intermediary, the HTTP server
> or intermediary may start doing HTTP-valid things to it, and those
> things will not be valid from WebSocket point of view.

Right -- and those things will prevent the connection, exactly as
intended. The idea is to make sure that if there is anything in between
that _isn't_ WebSocket-aware, the connection be dropped before the author
has any chance of sending data down the pipe. If we didn't do this, then
it's possible that, e.g., Squid could be tricked into sending data from
third-party servers in a way that the WebSocket client could not detect,
thus breaching the same-origin security model.

> I want to avoid the following Squid bug report 5 years from now:
>
> Title: Squid breaks FooBar
>
> Comment1: FooBar, a WebSocket application, works fine unless there is a
> "transparent" Squid proxy in the way. I have attached a packet trace.
>
> Comment2: Closed as invalid. Squid seems to be handling the HTTP
> messages correctly. Squid is not responsible to what happens after
> Upgrade, inside the tunnel.
>
> Comment3: Reopened as critical. I need to make this work. Please do
> something! I have read somewhere that if Squid would not add a Via or
> XFF header and also that extra space character after a column,
> everything would just work!
>
> Comment4: Changed to enhancement: Rewrite Squid to support
> WebSocket-compatible Upgrade exchange. Meanwhile, consider writing a
> post-Squid eCAP module that will rewrite Squid-altered HTTP messages to
> conform to WebSocket.

If Squid changes the bytes that are sent from the client or by the server,
then this bug will likely exist, yes. So don't do that. :-) If a man-in-
the-middle proxy server modifies the bytes of connections it doesn't fully
understand, then WebSocket isn't the only thing that will break.

(Note that a min-in-the-middle proxy is not the same as a "transparent
proxy" as defined by the HTTP spec. Per spec, a "transparent proxy" is a
proxy that does not modify the request or response beyond what is required
for proxy authentication and identification.)

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