<meta http-equiv="Content-Type" content="text/html; charset=GB18030"><pre class="tw-data-text tw-text-large tw-ta" data-placeholder="翻译" id="tw-target-text" dir="ltr" style="unicode-bidi: isolate; line-height: 36px; background-color: rgb(248, 249, 250); border: none; padding: 2px 0.14em 2px 0px; position: relative; margin-top: -2px; margin-bottom: -2px; resize: none; overflow: hidden; width: 270px;"><font color="#202124" face="Verdana"><span style="font-size: 28px;">Thank you for your detailed answer.
As you said, Squid does not support rewrite-url after ssl-bumped.
but I don't understand why it is designed this way.
If I want to modify the ssl-bumped returned content, not through 302,307 http redirect url?
can I use ecap or other methods to achieve it?</span></font></pre><div><br></div><div><br></div><div style="font-size: 12px;font-family: Arial Narrow;padding:2px 0 2px 0;">------------------ 原始邮件 ------------------</div><div style="font-size: 12px;background:#efefef;padding:8px;"><div><b>发件人:</b> "Alex Rousskov"<rousskov@measurement-factory.com>; </div><div><b>发送时间:</b> 2023年9月21日(星期四) 凌晨0:57</div><div><b>收件人:</b> "squid-users"<squid-users@lists.squid-cache.org>; </div><div><b>主题:</b> Re: [squid-users] ssl-bump peek and select pinned destination failed</div></div><div><br></div>On 2023-09-20 04:17, linfengfeiye wrote:<br>> Hi, what does "PeerSelector186 found pinned, destination" that appears <br>> in the Squid log mean?<br><br>Please note that Squid debugging logs (cache.log at level 3 and above) <br>are for developer use. This mailing list is not. In triage, I recommend <br>focusing on access.log, non-debugging cache.log, and other admin-focused <br>resources while leaving debug log analysis to Squid developers.<br><br><br>Roughly speaking, the logging message you are asking about means that <br>Squid code tasked with selecting where to forward the request found a <br>previously opened Squid-to-server connection that was assigned (i.e., <br>"pinned") to the client-to-Squid connection on which that request was <br>received. In most cases, that connection will be used for that request.<br><br>In SslBump context, a Squid-to-server TCP connection gets pinned to the <br>corresponding client-to-Squid TCP connection because that <br>Squid-to-server TLS connection uses TLS settings specific to that client <br>and vice versa. Pinning minimizes surprises/changes for TLS clients that <br>are not expected to be bumped. It also creates various problems.<br><br><br>> The destination address <a href="https://my.local.web" rel="noopener" target="_blank">https://my.local.web</a> in this log is returned by <br>> URL-Rewrite, rewrite-url=<a href="https://my.local.web," rel="noopener" target="_blank">https://my.local.web,</a> which is a local web <br>> service of mine.But it failed directly after peer_select. I think this <br>> should be related to ssl-bump.<br><br>AFAICT, without significant Squid code adjustments, one cannot rewrite <br>destinations of bumped requests because rewritten requests will still be <br>assigned the old pinned Squid-to-server connections despite request <br>destination changes.<br><br><br>> My decryption configuration is roughly as <br>> follows.<br>> <br>> The strange thing is that as long as I comment these two lines,<br>> <br>> #acl step1 at_step SslBump1<br>> #ssl_bump peek step1 all<br>> <br>> the pinned destination disappears and the access is successful,why?<br><br>Roughly speaking, without SslBump (and certain other special cases), <br>there is no need to pin connections and there is no URL rewriting (for <br>encrypted requests).<br><br><br>HTH,<br><br>Alex.<br><br><br><br>> ##follows is ssl-bump config################<br>> <br>> http_port 3126 intercept<br>> https_port 3129 intercept ssl-bump generate-host-certificates=on <br>> options=NO_SSLv3 tls-min-version=1.2 dynamic_cert_mem_cache_size=4MB <br>> tls-cert=/os/usr/local/proxy/etc/cert.pem<br>> http_port 3128 ssl-bump generate-host-certificates=on options=NO_SSLv3 <br>> tls-min-version=1.2 dynamic_cert_mem_cache_size=4MB <br>> tls-cert=/usr/local/proxy/etc/cert.pem<br>> acl step1 at_step SslBump1<br>> sslcrtd_program /os/usr/local/proxy/libexec/security_file_certgen -s <br>> /usr/local/proxy/var/lib/ssl_db -M 4MB<br>> sslcrtd_children 5<br>> ssl_bump peek step1 all<br>> ssl_bump splice white_list<br>> ssl_bump bump bump_domain<br>> ssl_bump bump all<br>> http_access allow all<br>> <br>> <br>> _______________________________________________<br>> squid-users mailing list<br>> <a href="mailto:squid-users@lists.squid-cache.org" rel="noopener" target="_blank">squid-users@lists.squid-cache.org</a><br>> <a href="https://lists.squid-cache.org/listinfo/squid-users" rel="noopener" target="_blank">https://lists.squid-cache.org/listinfo/squid-users</a><br><br>_______________________________________________<br>squid-users mailing list<br><a href="mailto:squid-users@lists.squid-cache.org" rel="noopener" target="_blank">squid-users@lists.squid-cache.org</a><br><a href="https://lists.squid-cache.org/listinfo/squid-users" rel="noopener" target="_blank">https://lists.squid-cache.org/listinfo/squid-users</a><br><style type="text/css">.qmbox style, .qmbox script, .qmbox head, .qmbox link, .qmbox meta {display: none !important;}</style>