
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><p data-start="1520" data-end="1548">Thank you for your response.</p><p data-start="1550" data-end="1642">Based on your reply, we have reviewed the configuration and observed the following behavior.</p><h3 data-start="1649" data-end="1685">■ Relevant Configuration Snippet</h3><pre class="overflow-visible!" data-start="1687" data-end="1865"><div class="contain-inline-size rounded-md border-[0.5px] border-token-border-medium relative bg-token-sidebar-surface-primary"><div class="flex items-center text-token-text-secondary px-4 py-2 text-xs font-sans justify-between h-9 bg-token-sidebar-surface-primary dark:bg-token-main-surface-secondary select-none rounded-t-[5px]">acl bump_targets ssl::server_name "/home/user001/ssl_bump/ssl_bump_domain"</div><div class="overflow-y-auto p-4" dir="ltr"><code class="whitespace-pre! language-squid">ssl_bump stare step1

ssl_bump bump step2 bump_targets

ssl_bump splice step2 !bump_targets

</code></div></div></pre><p data-start="1867" data-end="1931">The <code data-start="1871" data-end="1911">/home/user001/ssl_bump/ssl_bump_domain</code> file includes only:</p><pre class="overflow-visible!" data-start="1933" data-end="2017"><div class="contain-inline-size rounded-md border-[0.5px] border-token-border-medium relative bg-token-sidebar-surface-primary"><div class="overflow-y-auto p-4" dir="ltr"><code class="whitespace-pre! language-bash">[root@host squid]<span class="hljs-comment"># cat /home/user001/ssl_bump/ssl_bump_domain</span>

github.com</code></div></div></pre></div><div><h3 data-start="2024" data-end="2043">■ Observed Logs</h3><pre class="overflow-visible!" data-start="2045" data-end="2317"><div class="contain-inline-size rounded-md border-[0.5px] border-token-border-medium relative bg-token-sidebar-surface-primary"><div class="overflow-y-auto p-4" dir="ltr"><code class="whitespace-pre! language-log">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

</code></div></div></pre><p data-start="2319" data-end="2532">As <code data-start="2322" data-end="2335">mariadb.org</code> is <strong data-start="2339" data-end="2383">not listed in the <code data-start="2359" data-end="2376">ssl_bump_domain</code> file</strong>, 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.</p></div><div><h3 data-start="2539" data-end="2569">■ Main Clarification Point</h3><p data-start="2571" data-end="2613">The key point we would like to confirm is:</p><blockquote data-start="2615" data-end="2896"><p data-start="2617" data-end="2896"><strong data-start="2617" data-end="2896">In a configuration where <code data-start="2644" data-end="2654">ssl_bump</code> 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?</strong></p></blockquote><p data-start="2898" data-end="2915">Or alternatively:</p><blockquote data-start="2917" data-end="3091"><p data-start="2919" data-end="3091"><strong data-start="2919" data-end="3091">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?</strong></p></blockquote><p data-start="3093" data-end="3199">We would greatly appreciate clarification on the expected behavior and underlying mechanism in such cases.</p></div><div><br></div><div><br><blockquote type="cite"><div>2025/05/28 1:19、Alex Rousskov <rousskov@measurement-factory.com>のメール:</div><br class="Apple-interchange-newline"><div><div>On 2025-05-27 10:37, Yves MARTIN wrote:<br><br><blockquote type="cite">My team expects to transparently rewrite requests through squid, replacing original URL/hostname by another target URL/host.<br>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.<br>To do so, we have used squid-urlrewrite and it works well for HTTP request, even if rewrite targets HTTPS URL.<br>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.<br></blockquote><br>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.<br><br>I have not checked, but speculate that rewriting request target does not trigger opening a new Squid-to-server TLS connection and re-pinning.<br><br>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.<br><br><br>HTH,<br><br>Alex.<br>_______________________________________________<br>squid-users mailing list<br>squid-users@lists.squid-cache.org<br>https://lists.squid-cache.org/listinfo/squid-users<br></div></div></blockquote></div><br></body></html>