Squid 5.0.3 Cache_Peer Authentication Issue

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Squid 5.0.3 Cache_Peer Authentication Issue

Paul-4
Hello,

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| 5,3| IoCallback.cc(112) finish: called for conn30 local=10.10.10.60:41270
remote=10.10.10.167:8080 FIRSTUP_PARENT FD 17 flags=1 (0, 0)
kid1| 5,3| Read.cc(93) ReadNow: conn30 local=10.10.10.60:41270
remote=10.10.10.167:8080 FIRSTUP_PARENT FD 17 flags=1, size 65535, retval 978,
errno 0
kid1| 11,2| HttpTunneler.cc(323) handleResponse: Tunnel Server conn30
local=10.10.10.60:41270 remote=10.10.10.167:8080 FIRSTUP_PARENT FD 17 flags=1
kid1| 11,2| HttpTunneler.cc(326) handleResponse: Tunnel Server RESPONSE:
---------
<HEAD><TITLE>Proxy Authorization Required</TITLE></HEAD>
<BODY BGCOLOR="white" FGCOLOR="black"><H1>Proxy Authorization
Required</H1><HR>
<FONT FACE="Helvetica,Arial"><B>
Description: Authorization is required for access to this proxy</B></FONT>
<HR>
<!-- default "Proxy Authorization Required" response (407) -->----------
kid1| 83,3| HttpTunneler.cc(345) bailOnResponseError: unsupported CONNECT response
status code [state:w FD 17 job22]
kid1| TCP connection to 10.10.10.167/8080 failed
    current master transaction: master57
kid1| 83,5| HttpTunneler.cc(404) callBack: conn30 local=10.10.10.60:41270
remote=10.10.10.167:8080 FIRSTUP_PARENT FD 17 flags=1 [state:w FD 17 job22]
--------------

Is this a mis-configuration? or have I mis-understood how cache_peer works?

regards,
Paul


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid 5.0.3 Cache_Peer Authentication Issue

Alex Rousskov
On 1/7/21 2:43 PM, [hidden email] 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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid 5.0.3 Cache_Peer Authentication Issue

Paul-4
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, [hidden email] 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
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid 5.0.3 Cache_Peer Authentication Issue

Alex Rousskov
On 1/8/21 12:18 PM, [hidden email] 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, [hidden email] 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
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
>

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users