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

[Alex Rousskov]

On 2026-03-08 06:17, Anthony Pankov wrote:
> 
> On 7 марта 2026 г., 1:12:04 you wrote:
> 
>> 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.
> 
> This was my initial attempt. I was long fighting to get that configuration (ssl_bump bump all) to work. There are my posts https://bugs.squid-cache.org/show_bug.cgi?id=5486 related to get it to work. But has no luck. Things start worked only when steps added.
> 
> So 'ssl_bump bump all' alone give me NO_CIPHER_OVERLAP. Unfortunately.


Understood. This will complicate completion of your project. Going 
forward, I see two primary directions:

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.

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.

Option A probably requires less development work. With some effort, 
option B changes/fixes might become useful for the Squid Project.

I cannot volunteer to implement either option, but I can give hints for 
Option A. Whether those hints would be enough to help you reach your 
goal is unknown.


HTH,

Alex.