[squid-users] 回复： ssl-bump peek and select pinned destination failed

[linfengfeiye]

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 at measurement-factory.com>; 
发送时间: 2023年9月21日(星期四) 凌晨0:57
收件人: "squid-users"<squid-users at lists.squid-cache.org>; 
主题: Re: [squid-users] ssl-bump peek and select pinned destination failed



On 2023-09-20 04:17, linfengfeiye wrote:
> 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=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 at lists.squid-cache.org
> https://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
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/20230923/c5544a90/attachment.htm>