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.
_______________________________________________
squid-dev mailing list
[email protected]
https://lists.squid-cache.org/listinfo/squid-dev
