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

[Alex Rousskov]

On 2026-04-07 10:55, Anthony Pankov wrote:
> 
> Friday, April 3, 2026, 6:47:26 PM, you wrote:
> 
>> On 2026-04-03 07:20, Anthony Pankov wrote:
>>>> I've tried to call getSslContextStart() in startPeakAndSplice().
>>>> But the problem is:
>>> getSslContextStart() return synchronously in most cases after calling getSslContextDone().
>>>> But in the case of #if USE_SSL_CRTD (my case) it return after sending request to CRTD without calling getSslContextDone().
>>> getSslContextDone() will be called further in sslCrtdHandleReplyWrapper().
>>>> So we are back in startPeakAndSplice() without getSslContextDone() and connections are closed.
>>>> Is there a preferred way to solve this problem?
> 
>> AFAICT, in your case, startPeekAndSplice() should do nothing when the added getSslContextStart() call returns. From https://ml-archives.squid-cache.org/squid-dev/2026-March/009992.html : getSslContextStart() should eventually trigger a call to getSslContextDone() with a non-nil Security::ContextPointer that calls httpsCreate() with the transaction-specific security context (SNI, etc.).
> 
> There are conditional-branch inside getSslContextStart():
> ...
> 
> if (sslServerBump && (sslServerBump->act.step1 == Ssl::bumpPeek || sslServerBump->act.step1 == Ssl::bumpStare)) {
>          %branch A%
>          ...
>              Ssl::configureUnconfiguredSslContext(ctx, certProperties.signAlgorithm, *port);
>   } else {
>          %branch B%
> ...
>             getSslContextDone(dynCtx);
>          }
> 
> If I understand correctly branch B must be choosen for my case.


Yes, assuming you are not using an external certificate generator helper.

Earlier, you said that you _are_ using that helper. With the helper, I 
expect the above `if/else` statement to be unreachable in 
successful/interesting cases because the corresponding `try{}` block 
ends with `return`. In helper cases, we get to getSslContextDone() via 
sslCrtdHandleReply().


> But my configuration (as discussed previously) is:
> ssl_bump stare ssl_bump_step_1
> ssl_bump bump all


You have two options AFAICT:

1) Hard-code the right decision logic (for now). Ignore ssl_bump 
configuration in places where the right decision logic is hard-coded for 
your specific use case. I recommend this simpler approach as a starting 
point.

2) Adjust code to interpret that old ssl_bump configuration differently, 
to match/enable your new logic instead of whatever the existing code is 
doing.


> So the condition inside getSslContextStart() is true and the branchA is choosen. 

> Do anybody have any idea about what case is behind this:
> if (sslServerBump && (sslServerBump->act.step1 == Ssl::bumpPeek || sslServerBump->act.step1 == Ssl::bumpStare)) {

I am not sure I understand the question, but, based on what you are 
saying above, this `if` statement covers various cases matching in your 
old "stare during step1" configuration. It also covers the cases covered 
by a similar "peek during step1" configurations. In other words, this 
`if` statement covers cases where the final action is configured to 
happen sometime _after_ step1.


>     // This is the Step2 of the SSL bumping
>     assert(sslServerBump);

Ignoring that source code comment may be a good idea. I have not checked 
all the details, but it feels misleading/stale to me.


HTH,

Alex.