Re: Hello from Mozilla

On Thu, 16 Jul 2009, Amos Jeffries wrote:
> >
> > We actually used to do that, but we got requests to make it more
> > compatible with the HTTP Upgrade mechanism so that people could add
> > the support to their HTTP servers instead of having to put code in
> > front of their servers.
>
> Well if those people are willing to re-write their web servers for this
> they should be able to re-write them to do the TCP switching itself on
> receipt of the first packets, rather than after screwing up the entire
> process.
>
> You already specify that receiving N bytes with layout ABC followed by
> DEF means the entire stream is WebSockets and verify it. Simply specify
> it such that there is no resemblance to HTTP. The compatible servers
> will handle it. Intermediaries will see non-HTTP and handle it properly,
> non-compliant servers will terminate the WebSockets connection properly.
> We already routinely do this in proxies for P2P and other traffic forms.
> The only reason WebSockets is having trouble is because it's using a
> valid HTTP format.

So Squid when used as a man-in-the-middle proxy will allow arbitrary
traffic through port 80 if it isn't HTTP traffic?

This advice contradicts other advice we've gotten to the effect that if we
send any content over port 80, it absolutely must be HTTP-compatible.

> > Well, since Upgrade is a by-hop packet, apparently that's a moot point
> > anyway, because man-in-the-middle proxies will always break it if
> > they're present. So I'm not convinced that allowing HTTP modifications
> > matters.
>
> The key word there is **always**. Which is not true.
>
> There are many administrators who go out of their way for truely
> semantic transparency. They will preserve the handshake. The proxy will
> appear to be a valid WebSockets server, handshake, then break on the
> non-HTTP data of following requests.

Could you elaborate on this? Why would a transparent proxy meddle with
bytes after it has seen a successful Upgrade? Doesn't this contradict the
requirements on transparent proxies in the HTTP spec?

> > But the point is that it is a recognisable handshake and so could be
> > implemented as a switch before hitting the HTTP server, or it could be
> > implemented in the HTTP server itself (as some people apparently
> > want). It fails with man-in-the-middle proxies, but then that's what
> > the TLS-over- port-443 solution is intended for.
>
> The first entire year I was with the Squid project was spent emailing
> people repeating over and over: "Squid is an HTTP proxy it does NOT
> proxy protocol X" and this was for FTP/SMTP/RTSP which only roughly
> resemble HTTP in the header layout. The currently spec'd WebSockets
> handshake will fool even more people since it looks for all intents and
> purposed _exactly_ like an HTTP request.

For all intents and purposes, it _is_ an HTTP request. It's an Upgrade
request. It seems that man-in-the-middle proxies would break all Upgrades,
the way you've described them.

> Right down to the HTTP/1.1 reserved protocol label (do get that changed
> please).

If we're faking HTTP, then it has to look like HTTP.

I'm getting very mixed messages here.

Is there a reliable way to open a bidirectional non-HTTP TCP/IP connection
through a Squid man-in-the-middle proxy over port 80 to a remote server
that normally acts like an HTTP server? If so, what is the sequence of
bytes that will act in this way?

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