[squid-users] Making squid into socks proxy

[Grant Taylor]

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