Re: Hello from Mozilla

Robert Collins wrote:
> 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).

I'm open to adding 815, maybe 81. Though as Robert says, the utility
may not be as much as the authors think.

CONNECT to port-80 by default is IMO not an option. It pretty much
defeats all the other HTTP-level security measures. Port-81 is
borderline on the risky side. Considering the number of proxies and
web-apps which historically use it for regular internal LAN HTTP stuff.
  Admin who know they need CONNECT to those ports are free to do so of
course.

IIRC, there is also another HTTPS port 5-something, and some other
protocols needing consideration in the same commit.

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

These are the reponse codes I'm aware of people trying to use with Squid
CONNECT. For now the admins are hacking around the browsers that don't
support custom errors.

Taking 404 access denied as assumed.

  * the authenticated proxy (407) response needing a login popup.

  * the HTTPS->HTTP downgrade response (301). This seems to be popular
for some reason where corporate policy prohibits end-to-end HTTPS with
external sources. Our nasty SslBump may cover this case though. I'm open
to leaving it a problem :)

  * the captive-portal access response (303,305, 'old'-style setups:
302). These are basic requirements for captive portal design. CONNECT
requests may loop in silent failures without it.
   There are actual instances already of that scripting attack your bug
mentions, being used as the portal login mechanism because the secure
redirect with 302 does not always work. HTTP <meta /> redirects are
another active-body case they don't mention in the report.

  * as HTTP/1.1 is implemented its likely that Squid will generate
(402,403,405,408,413,414,505) messages in response to CONNECT. Some are
already generated now. Being overridden with something sensible is no
bother to Squid, but the proxy page may be useful to you.

There may be others I'm not aware of.

As Robert points out a proxy context to display these proxy-related
errors safely. Particularly if containing any kind of active body.

I'm open to changing any of the error codes and messages Squid is
providing that do not match RFC 2616 yet if it would assist. Just point
any out found. A few of the 5xx are already known and status changes are
on the roadmap.

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

It was an oversight on my part when making the RFC1918 additions. The
security issues balance out in different ways as far as I can see for
both bastion hosts and internal workstations.

I'm planning to correct it shortly.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE6 or 3.0.STABLE16
   Current Beta Squid 3.1.0.9