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

Thu May 29 00:38:20 UTC 2025

Thank you for your response.

So it is by design that when SSL_Bump is enabled, Squid does not return a “403” error for the CONNECT request, but instead returns “403” after the subsequent GET request.

Also, thank you for suggesting a possible workaround.

You can consider this inquiry closed.

Thanks again!

iPhoneから送信

> 2025/05/28 22:37、Cloutier, Matt <Matt.Cloutier at hexcel.com>のメール:
> 
> Hello,
> 
> The person working on this project is no longer employed at this company.  Thank you for the help on this, but we are going to go in another direction.
> 
> Thank you,
> Matt Cloutier
> 
> 
> 
> This message contains information from Hexcel which may be proprietary or privileged. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this transmission in error, please notify me immediately by telephone or email.
> 
> Protecting your personal data matters to us. For more information about how we may use your personal data, read our Privacy Policy.
> 
> 
> 
> -----Original Message-----
> From: squid-users <squid-users-bounces at lists.squid-cache.org> On Behalf Of Alex Rousskov
> Sent: Wednesday, May 28, 2025 9:23 AM
> To: 中山稀斗 <nakayamakito at icloud.com>; squid-users at lists.squid-cache.org
> Subject: Re: [squid-users] How to do transparent rewrite with https requests?
> 
> Caution: This email originated from outside of Hexcel. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> 
> 
>> 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://mari/
>> adb.org%2Fdonate%2F&data=05%7C02%7Cjosh.piana%40hexcel.com%7C204fa12a9
>> f9e4474188208dd9dec17a2%7C4248050df19546d5ac9c0c7c52b04cae%7C0%7C0%7C6
>> 38840359549441010%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi
>> OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7
>> C%7C%7C&sdata=Q82TrO03Ee4Z5rmCBSMDYLRgD4LyRL%2BLbu5y5yHqFcs%3D&reserve
>> d=0 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://gi/
>>>> thub.com%2Frchunping%2Fsquid-urlrewrite%2Fissues%2F3&data=05%7C02%7C
>>>> josh.piana%40hexcel.com%7C204fa12a9f9e4474188208dd9dec17a2%7C4248050df19546d5ac9c0c7c52b04cae%7C0%7C0%7C638840359549469713%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=1qoWRntXqGMAJU6ea0rpsCpSDKYkZYekXF%2FXIEI2i60%3D&reserved=0 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://lis/
>>> ts.squid-cache.org%2Flistinfo%2Fsquid-users&data=05%7C02%7Cjosh.piana
>>> %40hexcel.com%7C204fa12a9f9e4474188208dd9dec17a2%7C4248050df19546d5ac
>>> 9c0c7c52b04cae%7C0%7C0%7C638840359549482027%7CUnknown%7CTWFpbGZsb3d8e
>>> yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTW
>>> FpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=GMDv3HOK599Jjw94Lu8mvE%2Bnj
>>> 5s9hsjclXv8HKrD6%2Bw%3D&reserved=0
>> 
> 
> _______________________________________________
> 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/20250529/9527cd94/attachment-0001.htm>