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

Alex Rousskov rousskov at measurement-factory.com
Wed Sep 20 16:57:13 UTC 2023


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



More information about the squid-users mailing list