On 7/10/23 2:36 PM, Francesco Chemolli wrote:
Hi Robert,
Hi Francesco,
in my understanding that configuration turns Squid into a Socks
client. Outbound squid connections will then be proxied through a socks
proxy.
According to "this page" [1] linked from the "How to enable SOCKS5 for
Squid Proxy?" page [2] that Rob linked to, this seems like it is both
client /and/ server support.
--8<--
Details:
Squid handles many HTTP related protocols. But presently is unable to
natively accept or send HTTP connections over SOCKS.
The aim of this project will be to make http_port accept SOCKS
connections and make outgoing connections to SOCKS cache_peers so that
Squid can send requests easily through to SOCKS gateways or act as an
HTTP SOCKS gateway itself.
-->8--
Particularly germane are "accept ... HTTP connections over SOCKS", "make
http_port accept SOCKS connections", and "act as an HTTP SOCKS gateway
itself".
There might be a point, in some use cases, but I agree it's a stretch.
For instance it could help if there's a need to log URLs being accessed,
which socks by itself can' tdo; it might also work as a TLS interception
proxy which then needs to access some tightly-controlled network segment.
I can see a modicum of value in making Squid be a SOCKS client -- via
something more graceful than an LD_PRELOAD. I suspect that I'd turn to
a different SOCKS daemon before I'd turn to Squid as such. Dante comes
to mind.
I can see a LOT of value in SOCKS proxy support. Especially
authenticated access to the SOCKS proxy. Even more so if you
communicate with the proxy over encrypted channels
In some ways a SOCKS proxy acts sort of like a remote TCP/IP client /
stack. Combine this functionality with authentication and I can easily
allow controlled remote access into a segregated network and know which
authenticated user did what. Much like a VPN, but at the application level.
At a former job we used a lot of SOCKS servers. We would have a pair
(for redundancy) of SOCKS servers co-located at client networks and
required authentication of our employees to be able to utilize said
SOCKS servers. This configuration made it relatively trivial to our
employees change which SOCKS server they were using to switch between
the client they were doing administration work for.
One of the biggest advantages that I saw with SOCKS was the VPN like
connectivity, which required authentication, and the ability to filter
each packet / connection completely independently of the underlying
transport between the employee and the SOCKS server(s).
What's more is that the SOCKS servers appeared as if they were on the
client's network. Thus the, and the remote employees using them, could
access things on the client's network without any routing changes to the
client's network.
Think of it sort of like a remote extension of a network in a manner
that's completely divorced from the underlying network topology /
transport between clients and the SOCKS server.
This complete separation also means that things that aren't expressly
configured to use the SOCKS server can't accidentally be routed through
the SOCKS server. So when there is a security incident on the network,
it will be much better isolated to one side of the SOCKS server than if
it were a more traditional routed VPN type connection.
I can definitely see value in enabling Squid to be a SOCKS client to be
able to utilize / benefit from the perks that SOCKS servers can offer.
I see less value in having Squid be a SOCKS server.
That being said, I wonder how closely related SOCKS server functionality
and WebSocket support provide. Perhaps SOCKS can be another side door
into code needed to support WebSocket.
[1] Feature: SOCKS Support - http://wiki.squid-cache.org/Features/Socks
[2] How to enable SOCKS5 for Squid proxy? -
https://serverfault.com/questions/820578/how-to-enable-socks5-for-squid-proxy#820612
Grant. . . .
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
