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

[Alex Rousskov]

On 2025-05-27 20:07, 中山稀斗 wrote:
> 
> 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:
> 
> github.com


> 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.


When http_access rule denies a CONNECT request during SslBump step1, 
Squid bumps the client-to-Squid connection after receiving such a banned 
CONNECT request, waits for the client GET (or equivalent) request on the 
bumped connection, and then responds with an Access Denied error to the 
client. This behavior was implemented because most browsers refuse to 
show CONNECT errors to users; they only show GET errors.

If you do not like this behavior, you may, for example, configure your 
Squid to allow certain CONNECTs [during SslBump step1].

See http_access directive for the primary way to allow or deny requests.

See the following web page for interactions between http_access checks 
and ssl_bump activities:
https://wiki.squid-cache.org/Features/SslPeekAndSplice



> 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?*

The above summary is somewhat close to what is actually happening, but I 
recommend using the summary in my first paragraph above instead. Please 
keep in mind that it is the entire TLS connection that is being bumped 
(or spliced) rather than selected individual requests inside that 
connection. HTTP CONNECT request/response exchange (if any) happens 
before TLS.


> 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?*

Squid does not connect to the origin server in order to generate an 
error page. Roughly speaking[^1], Squid generates an error page based on 
the information already available at the time of error page generation. 
Depending on the ssl_bump step that encountered an error, that error 
page generation may come before or after Squid connects to the origin 
server. See the web page above for details.

[1]: Some error response details are collected later, from the 
subsequent GET request (if any). However, the primary error generation 
activity happens at error discovery time, before that GET. In a sense, 
Squid has a response before it has a request, which creates various 
problems/complications!..


HTH,

Alex.


>> 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
>