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

[Alex Rousskov]

On 2026-04-14 07:23, Anthony Pankov wrote:
> Monday, April 13, 2026, 10:30:33 PM, Alex wrote:
>> 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.

One can carefully hard-code specific logic as well, as a starting point, 
but there are several complex tradeoffs here, and it is _your_ call how 
to proceed.


> I assume that step1 is related to clientHello while step2 related to serverHello.

Roughly speaking, from ssl_bump rules/ACLs evaluation point of view, 
step1 uses info "before TLS", step2 uses "TLS Client Hello" info, and 
step3 uses "TLS Server Hello" info.

There are more details about each step on the wiki at 
https://wiki.squid-cache.org/Features/SslPeekAndSplice

However, the exact step boundaries are tricky to determine and folks 
mean different things in different contexts when they say "during stepN".


> If there is no peek/stare mode on step2 then no communication should
> be made to origin server.

I disagree: Matching a "bump" action during step2 should result in Squid 
sending its own Client Hello to the TLS server (among other things).

What is not immediately clear to me is whether that Squid must:

a) wait for TLS server Hello to fake a certificate before sending Squid 
server Hello to the TLS client or

b) use TLS client Hello to fake a certificate, establish a TLS 
connection with the TLS client, and only then open a TLS connection to 
the origin server.

SslPeekAndSplice page votes for (a) AFAICT: "Establish a TLS connection 
with the server (using client SNI, if any) and establish a TLS 
connection with the client (using a mimicked server certificate)."


> My case with step1==stare and step2 == bump will fit this logic.

SslPeekAndSplice page appears to disagree.


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

I hesitate calling any related logic "ideal", but I am not sure that 
current Squid works or should work the way you describe. AFAICT, 
according to SslPeekAndSplice, after step1, Squid interprets "bump" as

* "talk to the server and then respond to the client" rather than
* "respond to the client and then talk to the server".


HTH,

Alex.