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
