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?------------------ 原始邮件 ------------------
发件人: "Alex Rousskov"<rousskov@xxxxxxxxxxxxxxxxxxxxxxx>;
发送时间: 2023年9月21日(星期四) 凌晨0:57
收件人: "squid-users"<squid-users@xxxxxxxxxxxxxxxxxxxxx>;
主题: Re: [squid-users] ssl-bump peek and select pinned destination failed
> Hi, what does "PeerSelector186 found pinned, destination" that appears
> in the Squid log mean?
Please note that Squid debugging logs (cache.log at level 3 and above)
are for developer use. This mailing list is not. In triage, I recommend
focusing on access.log, non-debugging cache.log, and other admin-focused
resources while leaving debug log analysis to Squid developers.
Roughly speaking, the logging message you are asking about means that
Squid code tasked with selecting where to forward the request found a
previously opened Squid-to-server connection that was assigned (i.e.,
"pinned") to the client-to-Squid connection on which that request was
received. In most cases, that connection will be used for that request.
In SslBump context, a Squid-to-server TCP connection gets pinned to the
corresponding client-to-Squid TCP connection because that
Squid-to-server TLS connection uses TLS settings specific to that client
and vice versa. Pinning minimizes surprises/changes for TLS clients that
are not expected to be bumped. It also creates various problems.
> The destination address https://my.local.web in this log is returned by
> URL-Rewrite, rewrite-url="" href="https://my.local.web," rel="noopener" target="_blank">https://my.local.web, which is a local web
> service of mine.But it failed directly after peer_select. I think this
> should be related to ssl-bump.
AFAICT, without significant Squid code adjustments, one cannot rewrite
destinations of bumped requests because rewritten requests will still be
assigned the old pinned Squid-to-server connections despite request
destination changes.
> My decryption configuration is roughly as
> follows.
>
> The strange thing is that as long as I comment these two lines,
>
> #acl step1 at_step SslBump1
> #ssl_bump peek step1 all
>
> the pinned destination disappears and the access is successful,why?
Roughly speaking, without SslBump (and certain other special cases),
there is no need to pin connections and there is no URL rewriting (for
encrypted requests).
HTH,
Alex.
> ##follows is ssl-bump config################
>
> http_port 3126 intercept
> https_port 3129 intercept ssl-bump generate-host-certificates=on
> options=NO_SSLv3 tls-min-version=1.2 dynamic_cert_mem_cache_size=4MB
> tls-cert=/os/usr/local/proxy/etc/cert.pem
> http_port 3128 ssl-bump generate-host-certificates=on options=NO_SSLv3
> tls-min-version=1.2 dynamic_cert_mem_cache_size=4MB
> tls-cert=/usr/local/proxy/etc/cert.pem
> acl step1 at_step SslBump1
> sslcrtd_program /os/usr/local/proxy/libexec/security_file_certgen -s
> /usr/local/proxy/var/lib/ssl_db -M 4MB
> sslcrtd_children 5
> ssl_bump peek step1 all
> ssl_bump splice white_list
> ssl_bump bump bump_domain
> ssl_bump bump all
> http_access allow all
>
>
> _______________________________________________
> squid-users mailing list
> squid-users@xxxxxxxxxxxxxxxxxxxxx
> https://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx https://lists.squid-cache.org/listinfo/squid-users
