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