[squid-users] How to do transparent rewrite with https requests?

[中山稀斗]

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 at 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 <rousskov at 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 at lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20250528/8c40de60/attachment.htm>