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.clout...@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-boun...@lists.squid-cache.org> On Behalf Of > Alex Rousskov > Sent: Wednesday, May 28, 2025 9:23 AM > To: 中山稀斗 <nakayamak...@icloud.com>; squid-users@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 <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://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@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@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
