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

[Anthony Pankov]

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've got in squid-fronted:
>> 
>> 2026/03/05 12:15:18.505 kid1| 44,3| peer_select.cc(305) ...

> Peer selection is Part 2. Before we get into that, we need to make sure that your Squid can bump the client _without_ getting into FwdState.cc, peer_select.cc, etc. Squid-to-peer logic.

> It is not clear to me yet whether bumping the client was successful in the above test. To confirm, please test using an HTTPS client that sends something that does not require Squid-to-peer communication from HTTP point of view. Squid should generate the response internally. The client should successfully get that Squid-generated response.

> Here are some suggestions:

> 1. GET request with an "unsupported-scheme://a.test/" URL.
> 2. TRACE request with a "Max-Forwards: 0" header.
> 3. Non-HTTP (i.e. unparseable as HTTP) garbage with enough new lines
>     to let Squid find the "end" of "headers".

> For Part 1, your goal is to prove that your HTTPS client successfully communicates with your Squid with zero packets going to peers or origin servers. You can even add a temporary "assert(false)" to FwdState::FwdState() to be reasonably sure.

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.

I've got
...
-----END CERTIFICATE-----
(!!!!) subject=CN = aws-1.freshports.org
issuer=myown, created by security_file_certg
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 2210 bytes and written 834 bytes
Verification error: self-signed certificate in certificate chain
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 19 (self-signed certificate in certificate chain)
---

In access.log:

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 notice (!!!) in s_client answer. Security_file_certg maked certificate for "subject=CN = aws-1.freshports.org". Such info may be obtained only by CONNECT to origin via peer_cache. 
That's why 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.


-- 
Best regards,
Anthony