Re: Hello from Mozilla

tor 2009-07-16 klockan 01:44 +0000 skrev Ian Hickson:

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

No, but support for tunneling WebSockets can be added, but not when it
looks and feels like a HTTP message.

> 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.

And what we are saying is that if you make something that looks like
HTTP and runs on port 80 it should be HTTP, not just something that
looks like HTTP but isn't compatible with HTTP and which will break if
processed as if it was HTTP.

The point Amos tried to make is that if it isn't HTTP (just resembles
HTTP but isn't compatible with HTTP) then it should not look like HTTP.

For us as a proxy it's easier to deal with something that is easily
identified as not-HTTP and switch stack entirely than to try to tweak
the HTTP processing to not break "looks-like-HTTP-but-isn't-HTTP"
applications.

> 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?

It won't. But it will touch the HTTP upgrade request, and possibly even
the 101 response status description.

If it at all supports Upgrade, but that is a different topic.

> 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.

The only part of your spec we talk about here is the binary coded
looks-like-HTTP-Upgrade sequence. What happens after the
"looks-like-HTTP-101-response" we don't care about.

> > 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.

And our point is DO NOT FAKE HTTP. Use HTTP.

To make the point explicit we already see one wire protocol (icecast,
used by shoutcast streaming) which uses a similar fake HTTP mechanism
like you. In this protocol the clients sends a quite well formed HTTP
request, but the response is in a slightly different protocol. When this
gets processed by an HTTP intermediary (proxy or frontend) things do
break in subtle way because the application isn't expecting the
transforms required by HTTP. For a long time noone noticed as Squid did
not conform to a specific part the HTTP specifications, but when Squid
was modified to follow HTTP specifications this application broke.

> 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?

Both yes and no.

There is experimental support available for transparent interception
operation to switch to tunnel mode when seeing non-HTTP traffic, but
this is not yet part of the official distribution (needs a bit more work
first). The use case for this is environments using transparent
interception for caching reasons but which accepts that there may be
non-HTTP applications also using port 80.

At some point we will also support switching to tunnel mode after seeing
a successful HTTP Upgrade sequence but we are not quite there yet. This
discussion is to make sure WebSockets do not break when processed via a
future Squid which do support HTTP Upgrade. The use case for this is
both transparently interception in the client network and frontend
intermediary setups in the web server network.

In a normal forward proxy environment the supported method is CONNECT,
but default policy (configuration) restricts this to port 443 and a few
other well-known SSL ports blocking port 80.

Related note to others following this discussion: Upgrade is hop-by-hop
not end-to-end.

Regards
Henrik
Received on Thu Jul 16 2009 - 09:49:27 MDT