Re: Hello from Mozilla

On Tue, 2009-07-07 at 17:01 -0600, Alex Rousskov wrote:
> > The reason I ask is because we're looking to take a patch that
> > implements the IETF "websockets" protocol:
> >
> > http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-17
> >
> > I noticed that in section 3.1.3 the spec relies implicitly on CONNECT
> > being allowed to arbitrary ports. But this is not the case for default
> > installs of squid, and thus I fear that the general approach may be flawed.

I think it has several serious challenges; I doubt it could be deployed
in (say) Australia *at all*.

> > I suppose we could ask that you allow arbitrary CONNECT access (or at
> > least to the "well-known" websockets ports: 80/81/815). But I'm
> > guessing that wouldn't help much, as it would probably take many years
> > for that change to roll out across the net.
>
> I would also expect many firewalls to block port 81 and 815 by default
> so even if Squid allows those ports, websocket clients that do not hide
> behind Squid will still have problems (unless websocket is restricted to
> proxies).

So squid has two primary uses:
 - caching
 - security

From a caching perspective, websockets are just overhead - uncacheable
content simply adds overhead to what squid has to do. Just using TCP/IP
would be a lot better and faster.

Many ISP's use interception techniques to deploy squid and other caches.
These operate by performing a MITM attack on TCP/IP traffic. Policy
limits in these deployments are often turned off (because users using
TCP/IP would expect to access any url), while at the same time lifetime
heuristics tend to be turned way up (to maximise the hit rate the ISP
can achieve). As such, I'd expect this spec to have requests fail all
over the place. There are mechanisms for such requests to be reissued on
fresh, direct TCP connections by the router that performed the
interception - but the specific toolchain deployed will vary how
successful that is. Note that this has nothing to do with the use of
Connect: - squid, or other proxies, would see the 'Upgrade:' request.

From a security perspective, there are two sub issues:
 - preventing malicous use (e.g. spam bouncing)
 - policy restrictions (acls, corporate policy, content filtering...)

Malicious use covers things like not being an open proxy, and not
permitting connections to SMTP servers for any clients. This is where
the default Connect limit comes in - and also the prevention of http
requests to port 25.

> > Any thoughts you have on the matter would be much appreciated. In
> > general, it seems that handling proxies correctly is turning out to be
> > one of the trickier parts of implementing a websockets-like API, so we
> > may want to pick your brains some more in the future with other ideas.
>
> What is the motivation behind adding more ports? Can websocket use port
> 80 (without CONNECT) and port 443 (with CONNECT)? I have noticed there
> is something about the Upgrade header in the websocket draft so perhaps
> that mechanism can be polished to implement a proper protocol switch? Or
> is that too late?

I'd like to understand the motivation behind not just using TCP/IP with
a SOCKS proxy. The whole websockets thing seems like baroque cruft, TBH.
A lot of complexity, more layers that things can go wrong in (and that
security holes can be found in).

> > 2) A totally unrelated issue: I assume by now you're aware that Firefox
> > (and all other major browsers besides Opera) now no longer renders
> > replies from squid or other proxies for failed HTTPS requests. For
> > details see
> >
> > https://bugzilla.mozilla.org/show_bug.cgi?id=479880
> >
> > I meant to email you about this before the patch went in, but then I got
> > busy :) I'm not sure that there's much to talk about now that the fix
> > is in (it's gross, and we theoretically ought to be able to do better,
> > but it would be a lot of work, so I don't think it's going to happen).
> > But I wanted you to know. It's really just a UI issue (you can tell I'm
> > a systems programmer...)

Thanks. It would be nice if mozilla would create a context *for the
proxy* and use that to show the non 200 response. Debuggability is
kindof important :).

> > P.S. So every time that I set up squid on my machine to test something,
> > it always denies access to me out of the box. I finally figured out
> > it's because you don't allow localhost connections by default. Should
> > you be adding a line like
> >
> > acl localnet src localhost
> >
> > to squid.conf? Is there a reason why you're allowing 10.0.0.1, etc. to
> > connect, but not localhost?

I'd be open to us changing this. It is a [small] risk for a bastion host
to allow connections from itself because a different account being
compromised then allows access via the proxy. I have no evidence to make
an assertion about the frequency of deployments on a bastion host vs
behind one, and so the only argument I have for preserving it is 'secure
as possible by default', which while a good argument isn't the end of
the discussion.

-Rob