On 10/25/22 11:03 AM, Matus UHLAR - fantomas wrote:
I think intercepting is better, more precise.
On 25.10.22 12:14, Grant Taylor wrote:
I think that Squid can be an interception proxy as it can filter /
alter content.
I also think that Squid (as an interception proxy) can be used
transparently.
intercepting connections and modifying content are two separate
functionalities, and "transparent proxy" is in RFC2616 defined as "not doing
the latter" while many people understand it as "doing the former".
That is why I prefer using "intercepting proxy" for case where connections
between clients and servers intercepted by proxy, without it being
configured in browsers.
those two are completely separate,
I'm not yet convinced.
both functionalities described above are independent on each other, squid
also supports both separately, which gives us four combinations.
proxy may be intercepting and modify content (e.g. filter),
including squid.
I guess it could be said that the transparency, or modification of
content, is one aspect and that how the client connects to the proxy,
explicit or implicit (network magic), could be another aspect.
+-------------+--------+
| transparent | opaque |
+----------+-------------+--------+
| explicit | 2 | 1 |
+----------+-------------+--------+
| implicit | 3 | 4 |
+----------+-------------+--------+
I believe that Squid can be either transparent and / or opaque
depending on it's configuration.
precisely, so what exactly aren't you convinced about? :-)
I also believe that Squid can be either explicit and / or implicit via
networking magic.
When I said that intercepting was a superset of transparent, I was
including all four quadrants.
I guess intercepting is what you have in second row, while transparent is
the first column, that doesn't seem as superset to me.
I guess PORT connections have to be allowed on the SOCKS server
which is I'd say not common (can be dangerous)
Yes, the PORT connection must be allowed. But the problem that I
found was that the PORT declaration has a timeout / finite time that
they would wait for connections. E.g. ten minutes in the example I
was looking at.
Have you noticed this with SOCKS server?
I guess this applies for firewalls that will disable connections to the port
later. But the same applies for PASV connections and the reply when
firewall at serer side is used.
What's more is that the PORT connections must be declared /per/
/expected/ /connection/. They aren't a generic forward traffic from
any Internet connected system into the SOCKS client.
passive connections are safe in case of ftp/ssl, where it's
impossible to know for the proxy/firewall who connects where.
I don't think that it's impossible. Rather it's just improbable.
When ssl/tls is used between client and server, intermediate gateways and
firewalls don't know what ports do endpoints agree on using PORT/PASV.
Unless they intercept SSL conneciton (which kinf od makes them FTP
endpoints) or the client supports and issues FTP command "CCC" which is
designed for this case. I'm afraid not many FTP clients do that.
It's technically possible to do TLS bump in the wire or other things
like known keys (non-ephemeral / non-PFS) or sharing ephemeral / PFS
keys from internal server with TLS monkey in the middle proxy. Such
is technically possible, just highly improbable.
agree.
the workaround is to use static list of ports at server side and configure
server firewall to statically allow connection to these ports (optionally
NAT them).
however this is already not a SQUID issue.
--
Matus UHLAR - fantomas, uhlar@xxxxxxxxxxx ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
I intend to live forever - so far so good.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
