Thursday, March 5, 2026, 10:55:03 AM, you wrote:
> On 05/03/2026 05:03, Anthony Pankov wrote: >> Hello, >> > I still want to modify squid in such a way that it can forward >> clients http traffic to a parent cache in plain form. I mean after >> bumping ssl (forntend-squid establish tls connection with a client) >> requests from client should goes to parent cache as a plain http >> ( GET etc.) That is, using parent cache as in good old days without >> https. >> > Connection between squids servers is already encrypted so I don't >> need any additional tls(security) layer. > That is a fallacy. > 1) The connection between Squid and the TLS endpoint re-encryptor is a new > vulnerability point. > 2) TLS is a pointA-to-pointB encryption method. > What you have is a A->B->C network setup. With B->C encryption provided by > yourself. > The client software is relying on A->C encryption (security keys etc, > negotiated between A and C). Not separate A->B then B->C encryption, where A > has no knowledge about C recipient security regarding A's data. >> Connection between squids servers is already encrypted so I don't >> need any additional tls(security) layer. > The reverse can also be said. Squid keeps things encrypted so you do not need > the extra layer. Due to the above, this is **more** secure than just TLS or > even what double-TLS implies. When underlying routing/encryption is rather complex maintaining encryption on app layer seems overwork. A TLS to be something about security and not just about encryption need certificates on both side. Which implies PKI. Which implies certificates management for squid. All this seems overwork when there is a security on underlying network. -- Best regards, Anthony _______________________________________________ squid-dev mailing list [email protected] https://lists.squid-cache.org/listinfo/squid-dev
