[squid-users] Squid 5.0.3 Cache_Peer Authentication Issue

[Paul at pjb.org.uk]

Thank you for responding.

> N.B. I assume you do not use SslBump -- the configuration snippet above
> does not show SslBump being used. SslBump does not support what you want
> per commit f5e1794 message.

I am using Ssl-bump, but on a different inbound port and it will never be for traffic heading 
out to this peer.  

There is an entry in my logs much earlier during the process (just before it does 
peer_select) which states:
kid1| 85,5| client_side_request.cc(1444) sslBumpAccessCheck: cannot SslBump this 
request 

Does this use of ssl-bump at any stage preclude the use of cache_peer authentication with 
CONNECT?  My http_port, various acls and ssl_bump statements are all after the config 
extract shown below.

> What kind of HTTP authentication does your client/peer use/expect?

>From the successful GET connections, I can see that the peer requests both a Negotiate 
and NTLM, my clients respond with a Negotiate.

regards,
Paul


On 7 Jan 2021 at 15:18, Alex Rousskov wrote:

> On 1/7/21 2:43 PM, Paul at pjb.org.uk wrote:
> 
> > I am currently using Squid 5.0.3 but have an issue when using a cache_peer (non-squid &  
> > outside my control) that requires authentication.  My Squid server doesn't require 
> > authentication and reading the documentation indicated that I need to set 
> > 'login=PASSTHRU' on my cache_peer line, which I have done.  This has enabled GET 
> > methods to work as expected, but CONNECT methods are failing.  The response from the 
> > peer is a '407' with both methods. 
> 
> > I am controlling access to the peer via an acl:
> 
> > ---------------
> > acl localClients src 10.10.1.0/24
> > http_access allow localClients
> > 
> > acl aclREDIRECT dstdomain "/etc/squid/redirect.txt"
> > cache_peer 10.10.10.167 parent 8080 0 no-query name=peerREDIRECT login=PASSTHRU 
> > connection-auth=on
> > cache_peer_access peerREDIRECT allow aclREDIRECT
> > cache_peer_access peerREDIRECT deny !aclREDIRECT
> > never_direct allow aclREDIRECT
> > always_direct deny aclREDIRECT
> > always_direct allow all
> > 
> > http_port 80 connection-auth=on
> > ---------------
> 
> 
> > An extract from my logs showing the failure:
> > kid1| 11,2| HttpTunneler.cc(326) handleResponse: Tunnel Server RESPONSE:
> > <!-- default "Proxy Authorization Required" response (407) -->----------
> > kid1| 83,3| HttpTunneler.cc(345) bailOnResponseError: unsupported CONNECT response 
> > status code [state:w FD 17 job22]
> 
> > Is this a mis-configuration? or have I mis-understood how cache_peer works?
> 
> N.B. I assume you do not use SslBump -- the configuration snippet above
> does not show SslBump being used. SslBump does not support what you want
> per commit f5e1794 message.
> 
> What kind of HTTP authentication does your client/peer use/expect?
> 
> The 407 response from the peer may be normal/expected (a part of HTTP
> authentication) or indicate a problem. If you do not get better
> suggestions, please show us the CONNECT request and response headers,
> exchanged between the client and your Squid and between your Squid and
> cache_peer (i.e. 4 headers total). You can use tools like
> tcpdump/wireshark to collect/render those plain text headers.
> 
> Alex.