[squid-dev] forward bumped traffic to parent in plain form

[Anthony Pankov]

Tuesday, March 10, 2026, 4:44:16 PM, you wrote:

> On 2026-03-10 06:51, Anthony Pankov wrote:
>> Monday, March 9, 2026, 3:55:40 AM, Alex wrote:

>>> Option A: Give up on trying to bump the client without talking to
>>> the TLS origin server first. Let Squid talk to the TLS origin
>>> server (directly or via a cache_peer) while bumping the client. We
>>> know that this part already works. Adjust Squid code to
>>> forget/close that TLS connection after the client gets bumped and
>>> forward subsequent GET requests to a cache_peer using a different
>>> plain text connection. This option is only viable if you can let
>>> your Squid talk to the TLS origin server (directly or via a
>>> cache_peer) during client bumping.


>> It seems to that I have to agree for the sake of going forward.
>> But I wander about consequences.
>> > a) Does ACL on steps will still work?

> Option A does not change how ssl_bump directive specifically or connection bumping in general is handled. Roughly speaking, modified Option A code runs _after_ the client and the server are bumped. If you successfully bump the client today, the same configuration will work in patched code.


>> ssl_bump stare step1
>> ssl_bump splice serverIsBank
>> ssl_bump bump all
>> > Will this configuration work for splicing ACL serverIsBank

> Yes, assuming it works today.


>> and all other goes to peer_cache in plain form when option A is realized?

> If you want to forward _all_ *bumped* traffic that way, yes. Otherwise, you will need a different/new configuration directive (and/or a new cache_peer flag) to tell Squid when (i.e. for which bumped connections) to use plain text forwarding and which cache_peer to use for that plain text forwarding.


>> b) OK, squid will connect to origin server. Will it force applying
>> ciphers/options from origin server to squid<->client TLS connection?
>> Will it have no effect and client<->squid connection will strictly
>> controlled by tls- options of http_port configuration directive?

> Option A does not plan to change those SslBump aspects. If they work for you today, they will continue to work. If they do not, you will need to make more/additional changes (orthogonal to Option A changes).


>>> Option B: Assume that the TLS client does not really need any
>>> origin server info and can be bumped without talking to that
>>> server. Adjust Squid code to make that kind of bumping work,
>>> probably by modifying client-first mode. This option is only viable
>>> if its assumption is correct. I do not know whether it is correct;
>>> I do not know what exactly causes those NO_CIPHER_OVERLAP errors,
>>> for example.


>> I'm a bit confusing about this option. Does it mean to revive
>> deprecated "client-first" mode?

> Short answer: "Yes, if that reduces your development effort".

> The name of Option B mode is of secondary importance right now. If you are not using unsupported/deprecated "client-first" name today for other reasons, then it might be easier for you to modify Squid to reuse that existing name. It could be argued that you will be fixing that mode, but the success or failure of that argument would depend on the outcome. More detailed analysis of the problem space is available in the old bug 4327 discussion at [^1], especially in comment #1.

> [^1]: https://bugs.squid-cache.org/show_bug.cgi?id=4327


>> Is it really possible when the squid experts say  this mode is "old
>> and very broken"?

> I do not see a contradiction between "X is old and very broken" and "modify X to work well [for your use case]". There may also be a disagreement/misunderstanding regarding the "very broken" assertion or terminology, but all those details seem unimportant for now.

> When/if you have working code, we will need to decide whether to accept it (with adjustments) for official inclusion into Squid.

> * If that future decision is not important for you, then you do not need to worry about it right now.

> * If it is important, then we should switch from the current presumed "hacking to make things work for me" mode to a well-developed proposal/RFC on how to address this part of your specific use case. That proposal would probably need to address (or at least study the overlap with) Bug 4327 concerns[^1].


> N.B. The anticipated hacks that forward bumped requests using plain text connections to cache_peers are not directly related to the "client-first" discussion above and will never be triggered by "client-first" (or any other ssl_bump) mode. If they ever make it into official code, they will need a separate trigger/configuration.

OK. 
I choose an option A. May be because that my first impression was that things must work that way. Also, I think that having more info in the connection establishment phase is better than having less. There is ambiguity of a connections maked by cache_peer. First CONNECT may go to one server while subsequent GET goes to another in case server name resolve to multiple IP addresses. I hope this will not turn into a big problem.

> If you want to forward _all_ *bumped* traffic that way, yes. Otherwise, you will need a different/new configuration directive (and/or a new cache_peer flag) to tell Squid when (i.e. for which bumped connections) to use plain text forwarding and which cache_peer to use for that plain text forwarding.

I surely plan to add flag to cache_peer internally. Something like 'bool plainBumped = true' inside a cache peer object. All code modification will be made under this raised flag.

I'm open to any startup hints for option A realization.

P.S. I'm working on IDE setup for now. Remote debugging was relatively easy but remote building need  more setup.

-- 
Best regards,
Anthony