Re: Hello from Mozilla

tor 2009-07-02 klockan 17:59 -0700 skrev Jason Duell:

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

As you already know it's a security measure. I would expect it to be
implemented by quite many as it's mentioned in the original Netscape
document where CONNECT was first specified. I am not sure if Netscape
still has that document, but it was later published as an internet-draft

http://tools.ietf.org/html/draft-luotonen-ssl-tunneling-03

        Due to this fact, the proxy cannot verify that the protocol
        being spoken is really SSL, and so the proxy configuration
        should explicitly limit allowed connections to well-known SSL
        ports (such as 443 for HTTPS, 563 for SNEWS, as assigned by the
        Internet Assigned Numbers Authority).

When CONNECT later entered HTTP standards-track via the TLS working
group it was for a slightly different model however (HTTP/1.1 Upgrade
mechanism), and that text ONLY talks about port 80 and the security
risks of allowing other ports.

http://tools.ietf.org/html/rfc2817#section-8.2

        A generic TCP tunnel is fraught with security risks. First, such
        authorization should be limited to a small number of known
        ports. The Upgrade: mechanism defined here only requires onward
        tunneling at port 80. Second, since tunneled data is opaque to
        the proxy, there are additional risks to tunneling to other
        well-known or reserved ports. A putative HTTP client CONNECTing
        to port 25 could relay spam via SMTP, for example.

And the HTTP Upgrade mechanism generally haven't taken off yet with most
of the net stuck in the https model, so there haven't been much (any
before you) demands for CONNECT to port 80.

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

As you can see above all specifications available for the CONNECT method
recommends very strict rules regarding which ports is allowed.

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

Indeed. And as discussed we would never ship a default config which
allows arbitrary ports, just a carefully selected list of ports.

For what it's worth neither 81 or 815 is registered with IANA, and the
web-sockets draft you referenced has expired.

Regards
Henrik
Received on Tue Jul 14 2009 - 21:35:27 MDT