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 hope this goal can be accomplished without Squid source code changes,
but I cannot promise that.
HTH,
Alex.
Part 2: Forwarding bumped GET requests to cache_peers "as is", without a second
layer of encryption.
This part depends on Part 1. Let's come back to this after Part 1 is working.
_______________________________________________
squid-dev mailing list
[email protected]
https://lists.squid-cache.org/listinfo/squid-dev
