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

[Anthony Pankov]

Monday, April 13, 2026, 10:30:33 PM, you wrote:

> 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().

This code is duplicated in getSslContextStart() and sslCrtdHandleReply().
If crtd is used then control flow leave getSslContextStart() before this code and appear in sslCrtdHandleReply() where the same lines of code are present.


> 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.

Frankly speaking I dislike hard coding specific logic. I still try to place my code carefully.

I assume that step1 is related to clientHello while step2 related to serverHello.
If there is no peek/stare mode on step2 then no communication should be made to origin server.
My case with step1==stare and step2 == bump will fit this logic.
Further, all code for mimicking(inheriting) certificate properties of origin server should be involved only when step2 is a  peek/stare mode.

Does this match ideal logic behind sslbump in squid project?




-- 
Best regards,
Anthony