Meanwhile, Henrik Nordstrom says:
|
| See RFC2817
I read this RFC, and while I don't profess to understanding
all if it just yet, section 8.2 has me concerned, especially
the last sentence:
8.2 Security Considerations for CONNECT
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.
As squid is configured today, assuming most defaults in place, with
modifications for site ACLs, like
acl Safe_ports port nn1
acl Safe_ports port nn2
acl CONNECT method CONNECT
http_access deny !Safe_ports
Where port 25, for example is not a Safe_port, then am I correct
in my assessment that tunnels to/from my squid proxy for port 25
will be disallowed?
If so, that is quite nice. I just wish I could disallow
incoming connections to port 25 of this tunneling type, where my
internal proxy has no bearing whatsoever. Since I cannot do that,
I have to rely on scanning/filtering email which has already
traversed port 25. <sigh>
deb
Received on Thu Nov 15 2001 - 09:51:56 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:04:15 MST