You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
>> > I still want to modify squid in such a way that it can forward
160
+
>> clients http traffic to a parent cache in plain form. I mean after
161
+
>> bumping ssl (forntend-squid establish tls connection with a client)
162
+
>> requests from client should goes to parent cache as a plain http
163
+
>> ( GET etc.) That is, using parent cache as in good old days without
164
+
>> https.
165
+
>> > Connection between squids servers is already encrypted so I don't
166
+
>> need any additional tls(security) layer.
167
+
168
+
> That is a fallacy.
169
+
170
+
> 1) The connection between Squid and the TLS endpoint re-encryptor is a new vulnerability point.
171
+
172
+
173
+
> 2) TLS is a pointA-to-pointB encryption method.
174
+
175
+
> What you have is a A->B->C network setup. With B->C encryption provided by yourself.
176
+
177
+
> 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.
178
+
179
+
180
+
>> Connection between squids servers is already encrypted so I don't
181
+
>> need any additional tls(security) layer.
182
+
183
+
> 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.
184
+
185
+
When underlying routing/encryption is rather complex maintaining encryption on app layer seems overwork.
186
+
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.
187
+
188
+
189
+
--
190
+
Best regards,
191
+
Anthony
192
+
193
+
194
+
From anthony.pankov at yahoo.com Thu Mar 5 09:26:59 2026
195
+
From: anthony.pankov at yahoo.com (Anthony Pankov)
196
+
Date: Thu, 5 Mar 2026 12:26:59 +0300
197
+
Subject: [squid-dev] forward bumped traffic to parent in plain form
> Or does the client need to see something from the TLS origin server certificate to work correctly?
349
+
No. I mean split policy for now: client<->squid-fronted, peer_cache<->origin
350
+
351
+
> In that case, you have to use something like "ssl_bump stare all" but it will complicate Part 2 changes.
352
+
353
+
> Part 2: Forwarding bumped GET requests to cache_peers "as is", without a second layer of encryption.
354
+
355
+
> This part depends on Part 1. Let's come back to this after Part 1 is working.
356
+
357
+
358
+
> HTH,
359
+
360
+
> Alex.
361
+
362
+
363
+
>> Connection between squids servers is already encrypted so I don't need any additional tls(security) layer.
364
+
>> > Also, for simplification, I assume never_direct directive for this traffic on a front-end.
365
+
>> I understand that it will preclude any checks for origin server certificate but this is not a problem because policy for origin may be applied in a parent cache.
366
+
>> > I tried to modify FwdState::noteConnection to avoid establishTunnelThruProxy() and FwdState::secureConnectionToPeerIfNeeded to avoid secureConnectionToPeer() but has no lack.
367
+
>> > They use request.flags sslBumped and sslPeek that I do not fully understand. sslPeek described as "internal ssl-bump request to get server cert" but it always True when I'm in noteConnection.
368
+
>> > Also I noted async SslBumpEstablish which call switchToHttps. Because of asyncs I can't fully understand where I can preclude switching connections to parent cache to "CONNECT" mode rather than using it plain.
0 commit comments