Re: Hello from Mozilla

On 07/02/2009 06:59 PM, Jason Duell wrote:

> Hi there! I'm doing some work for Mozilla on the network stack for
> Firefox, and there are a couple of items I wanted to run by the Squid
> development team.

Hello Jason,

    I am forwarding your email to squid-dev mailing list where it will
receive more attention.

> 1) I have a quick question about the limitations that you put by default
> on the CONNECT method. squid.conf contains
>
> # Deny CONNECT to other than SSL ports
> http_access deny CONNECT !SSL_ports
>
> So squid by default only allows CONNECT to port 443. I assume this is
> a rule-of-thumb security measure, since you figured that port 443 is the
> only common legitimate case for CONNECT? How long has this been the
> default behavior? Do you know if other proxy servers out there also do
> this?

You have identified the main reason correctly. This default has been
added many years ago but I do not know when. I would expect some other
popular proxies to restrict tunneling as well, but I have not tested it.

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

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

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

Yeah, looks like a browser security bug has been replaced with usability
and compliance bugs. There is nothing Squid can do about it but thank
you for letting is know as this info may be useful when troubleshooting.

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

Good question. I will let others answer it :-).

Thank you,

Alex.
Received on Tue Jul 07 2009 - 23:02:20 MDT