Thank you for your response. Based on your reply, we have reviewed the configuration and observed the following behavior.
■ Relevant Configuration Snippet acl bump_targets ssl::server_name "/home/user001/ssl_bump/ssl_bump_domain" ssl_bump stare step1 ssl_bump bump step2 bump_targets ssl_bump splice step2 !bump_targets The /home/user001/ssl_bump/ssl_bump_domain file includes only: [root@host squid]# cat /home/user001/ssl_bump/ssl_bump_domain github.com ■ Observed Logs 26.56.128.144 - - [28/May/2025:10:25:18 +0900] "CONNECT mariadb.org:443 HTTP/1.1" 200 0 "-" "curl/8.5.0" TCP_DENIED:HIER_NONE 26.56.128.144 - - [28/May/2025:10:25:18 +0900] "GET https://mariadb.org/donate/ HTTP/1.1" 403 4076 "-" "curl/8.5.0" NONE_NONE:HIER_NONE As mariadb.org is not listed in the ssl_bump_domain file, we expected it to be spliced. However, the log indicates that Squid is able to see the full HTTPS URL, implying the connection was actually bumped. ■ Main Clarification Point The key point we would like to confirm is: In a configuration where ssl_bump is enabled, does Squid still allow the initial CONNECT request (returning 200) even for non-whitelisted domains, then wait for the client to send a follow-up HTTPS request (e.g., GET), which is then bumped and blocked (e.g., 403) by Squid? Or alternatively: Is Squid intentionally connecting to the origin server after CONNECT in order to generate an error page (403 etc.) that can be properly displayed to the client browser? We would greatly appreciate clarification on the expected behavior and underlying mechanism in such cases. > 2025/05/28 1:19、Alex Rousskov <rouss...@measurement-factory.com>のメール: > > On 2025-05-27 10:37, Yves MARTIN wrote: > >> My team expects to transparently rewrite requests through squid, replacing >> original URL/hostname by another target URL/host. >> Main objective is to redirect original HTTPS requests triggered by “docker >> pull alpine” to a local mirrored registry without obvious information in >> user client that the obtained image comes from mirror: original image >> location is preserved, no specific proxy or mirror configuration in docker >> client/daemon to set. >> To do so, we have used squid-urlrewrite and it works well for HTTP request, >> even if rewrite targets HTTPS URL. >> But when original request is HTTPS, connection still goes to original >> URL/hostname IP address >> https://github.com/rchunping/squid-urlrewrite/issues/3 According to debug >> logs, the original request hostname is resolved to IP early and kept in >> internal context after squid-urlrewrite is invoked. > > In most cases, when bumping connections from a TLS client to Squid and from > Squid to TLS server, Squid "pins" (i.e. remembers) the Squid-to-server > connection and then (re)uses that pinned connection for all requests received > on the client-to-Squid connection. > > I have not checked, but speculate that rewriting request target does not > trigger opening a new Squid-to-server TLS connection and re-pinning. > > IIRC, a Squid that is configured to bump during SslBump step1 does not pin. > Such a configuration is rarely usable on a modern internet, but YMMV. > > > HTH, > > Alex. > _______________________________________________ > squid-users mailing list > squid-users@lists.squid-cache.org > https://lists.squid-cache.org/listinfo/squid-users
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org https://lists.squid-cache.org/listinfo/squid-users
