[squid-users] FW: Encrypted browser-Squid connection errors

[Matus UHLAR - fantomas]

>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 at fantomas.sk ; 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.