[squid-users] Squid 5.0.3 Cache_Peer Authentication Issue

[Alex Rousskov]

On 1/8/21 12:18 PM, Paul at pjb.org.uk wrote:

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

My assumption is correct then -- bugs notwithstanding, we can ignore
SslBump limitations here because they do not apply to your use case.


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

AFAICT, Squid documentation implies that Negotiate PASSTHRU
authentication should work in combination with connection-auth=on (which
you do have). This is not my area of expertise, but my previous
recommendation regarding sharing four CONNECT-related headers stands.

Alex.


> 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.
> 
> 
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>