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

[Alex Rousskov]

On 2026-03-06 10:13, Anthony Pankov wrote:
> Thursday, March 5, 2026, 8:13:26 PM, you wrote:
> 
>> On 2026-03-05 04:26, Anthony Pankov wrote:
>>> Wednesday, March 4, 2026, 9:43:45 PM, Alex wrote:
>>>> On 2026-03-04 11:03, Anthony Pankov wrote:
>>>>> I still want to modify squid in such a way that it can forward
>>>>> clients http traffic to a parent cache in plain form. I mean after
>>>>> bumping ssl (forntend-squid establish tls connection with a client)
>>>>> requests from client should goes to parent cache as a plain http (
>>>>> GET etc.)
>>>>> Let's split this problem into two parts:
>>>>> Part 1: Bumping the client.
>>>>> Do you want your Squid to bump the TLS client connection without talking to the TLS origin server?
>>> Yes, for simplicity.
>>>>>    Bugs notwithstanding, that should already be possible using unsupported "ssl_bump client-first all" or,
>>>> common conf :
>>>> http_port 100.100.100.100:8080 ssl-bump generate-host-certificates=on \
>>>     options=CIPHER_SERVER_PREFERENCE,NO_TLSv1,NO_SSLv3,NO_TLSv1_1 \
>>>     tls-dh=prime256v1:/usr/local/etc/squid/sq-dhparams.pem \
>>>     tls-cert=/usr/local/etc/squid/imc+.ots101.crt \
>>>     tls-key=/usr/local/etc/squid/key.ots101-imc.pem \
>>>     dynamic_cert_mem_cache_size=10MB

>>>> ssl_bump client-first all
>>>> There is an error on the client (NO_CIPHER_OVERLAP) and error on squid

>> OK. It sounds like the TLS client is unhappy with the unsupported client-first mode. Let's forget about that mode and focus on supported ones:


>>> ssl_bump stare ssl_bump_step_1
>>> ssl_bump bump all

> I run the  command
> 
>     printf "Gfriued qf \r\n fsdf\r\n\r\n" |openssl s_client -connect www.freshports.org:443 -proxy 100.100.100.100:8080
> 
> as I think it is non-http request as you described in 3.

Yes, this is probably good enough for now.

Side note: FWIW, in my s_client-driven tests, I add the following 
commands to the command before the pipe, to give s_client a bit of time 
to receive Squid response (if any):

   sleep 3;
   echo "Q" # quit s_client

> I've got
> (!!!!) subject=CN = aws-1.freshports.org
> issuer=myown, created by security_file_certg

> 1772808292.780    614 217.119.19.66 NONE_NONE/200 0 CONNECT www.freshports.org:443 - FIRSTUP_PARENT/fd05:562e:5a23::e25:3101 -
> 1772808292.784      0 217.119.19.66 NONE_NONE/400 3350 - error:invalid-request - HIER_NONE/- text/html
> 
> I have a breakpoint in FwdState::FwdState and it is fired.

I believe your test confirms that your Squid talks to the peer while 
bumping the client connection during step2. I was hoping for a different 
outcome (to reduce development work), but before we give up on achieving 
that outcome, please try the following "bump during step1" configuration:

     ssl_bump bump all

According to old bug 4327[^1], the above configuration results in Squid 
bumping the TLS client connection before contacting the origin server. 
What do you see in your environment? Is your client happy with this 
bumping? Or does it declare a NO_CIPHER_OVERLAP error you saw in the 
client-first test?

I will suggest next steps based on the above/third test outcome.


HTH,

Alex.

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


> I think the CONNECT in access.log relate to origin certificate info gathering and not to HTTP request processing.
> 
> 
> IIRC, in my previous attempt to hack a code I always run into sslPeek flag which was always true. Because sslPeek stay for "internal ssl-bump request to get server cert" I thinked this was an expected behavior.
> 
>