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

[Alex Rousskov]

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.


HTH,

Alex.


> Fri Sep 7 04:18:10 UTC 2018
> Amos Jeffries Fri Sep 7 04:18:10 UTC 2018
> Previous message (by thread): [squid-users] About SSL peek-n-splice/bump configurations
> ...
> That is what the old and very broken "client-first" behaviour used to be. It does not produce any errors from
> the proxy BUT leads directly to a huge pile of security vulnerabilities
> and nasty side effects that may never be seen by you.
> ...