[squid-users] Authentication Passthrough Failing

Fri Feb 27 01:12:50 UTC 2015

On 27/02/2015 7:38 a.m., Curtis.M wrote:
> Hi all, 
> 
> I have squid 2.7 setup on a Win2012R2 DC used for caching purposes. The main
> use is for caching Apple iOS updates but is also starting to be used for
> general web browsing. 
> 
> The issue I have is there is a web filtering system being used in this
> environment that relies on AD usernames to filter web traffic. When clients
> are configured with squid, they are essentially unfiltered. Reason being is
> the box squid runs off is excluded from filtering and it seems all clients
> using the configured proxy receive the same level of filtering as the host
> squid is running from. 
> 
> I have already researched this and found that I may need to use Connection
> Pinning but when the line "connection-auth=on" is added to the conf, squid
> refuses to start. 
> (Full error below) 
> 
> So my questions are: 
>      Am I right in trying to use Connection Pinning to resolve this issue? 

No connection pinning is enabled by default anyway. Its about relaying
credentials so the client can (try to) login to a website foolishly
using NTLM and/or Negotiate authentication.

It doesn't work for remote Internet traffic, but if the service the
credentials are being delivered to is on the local LAN it usually (but
not always) works well enough. Provided Squid is the only proxy between
client and service.

>      Am I missing code needed from the conf I mentioned? 
>       

I dont see any config related to Squid passing the HTTP traffic to this
web filtering system you mention. That would normally be done with
cache_peer. With that in place the upstream web filtering system does
the relevant auth and Squid pins connections to/from it which need to be
pinned.

> 
> Thanks for reading and I hope you can help! 
> 
> Kind Regards, 
> 
> Curtis. 
> 
> 
> Squid.conf 
> ----------------------------------------------------------------------------------------------------------------------- 
> http_port 3128 connection-auth=on 

Problem #1:
 Squid-2.7 does not contain the connection-auth=X parameter.

That "feature" is on by default in 2.7 with an option to disable. So
there is nothing you need to do to allow it to work.

> 
> acl all src all 
> acl manager proto cache_object 
> acl localhost src 127.0.0.1/32 
> acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 
> acl localnet src 10.0.0.0/8	# RFC1918 possible internal network 
> acl localnet src 172.16.0.0/12	# RFC1918 possible internal network 
> acl localnet src 192.168.0.0/16	# RFC1918 possible internal network 
> acl SSL_ports port 443 
> acl Safe_ports port 80	# http 
> acl Safe_ports port 21	# ftp 
> acl Safe_ports port 443	# https 
> acl Safe_ports port 70	# gopher 
> acl Safe_ports port 210	# wais 
> acl Safe_ports port 1025-65535	# unregistered ports 
> acl Safe_ports port 280	# http-mgmt 
> acl Safe_ports port 488	# gss-http 
> acl Safe_ports port 591	# filemaker 
> acl Safe_ports port 777	# multiling http 
> acl CONNECT method CONNECT 
> 
> http_access allow manager localhost 
> http_access deny manager 
> http_access deny !Safe_ports 
> http_access deny CONNECT !SSL_ports 
> 
> http_access allow localnet 
> 
> http_access deny all 
> 
> 
> 
> icp_access allow localnet 
> icp_access deny all 
> 
> 
> 
> hierarchy_stoplist cgi-bin ? 
> 
> maximum_object_size 3072000000 bytes 
> cache_dir aufs C:\squid\var\cache 256000 128 256 max-size=2048000000 
> 
> access_log c:/squid/var/logs/access.log squid 
> 
> Cache-Control: max-age=0, no-cache, no-store 
> Pragma: no-cache 

Problem #2:
The above two lines are HTTP protocol message headers. Not squid.conf
directives. Did you miss out a commmet "#" prefix on the line?

> refresh_pattern -i appldnld\.apple\.com 129600 100% 129600 ignore-reload
> ignore-no-store override-expire override-lastmod ignore-must-revalidate 
> refresh_pattern -i phobos\.apple\.com 129600 100% 129600 ignore-reload
> ignore-no-store override-expire override-lastmod ignore-must-revalidate 

Potential Problem #3:
 You are forcing Squid to ignore the HTTP/1.1 cache revalidation
features which need to be carefully handled by Squid when operating in
the presence of NTLM or Negotiate authentication.

What do you expect to happen when the 407 response is forced to be
cached and re-used with to all following requests for apple.com
downloads? eg. a HIT on a cached 407 is ... a 407 ... stored for 90 days
with no chance of alteration.

> refresh_pattern ^ftp:	1440	20%	10080 
> refresh_pattern ^gopher:	1440	0%	1440 
> refresh_pattern -i (/cgi-bin/|\?) 0	0%	0 
> refresh_pattern .	0	20%	4320 
> 
> acl shoutcast rep_header X-HTTP09-First-Line ^ICY.[0-9] 
> upgrade_http0.9 deny shoutcast 
> 
> acl apache rep_header Server ^Apache 
> broken_vary_encoding allow apache 
> 
> coredump_dir c:/squid/var/cache 
> ----------------------------------------------------------------------------------------------------------------------- 
> Full Error: 
> FATAL: Bungled squid.conf line 1: http_port 3128 connection-auth=on 
> Squid Cache (Version 2.7.STABLE8): Terminated abnormally.

That is from problem #1.

PS. Don't assume that its Squid being the problem. Even if connections
"only" have a problem when going through Squid.

Direct-to-origin server messages and proxy-relayed messages have
different format, different requirements, and different limitations. The
authentication mechanisms are also quite different in one critical way
(end-to-end vs hop-by-hop processing). In order to pass NTLM and
Negotiate authentication to the server through a proxy most of the
HTTP/1.1 features have to be understood and disabled by that proxy.
Squid-2.7 is HTTP/1.0 software with only a limited understanding of ~60%
of HTTP/1.1 features.

The modern Internet also has a mix of several other protocols (HTTP/2,
WebSockets, SPDY, QUIC) operating over what were once the HTTP-only
ports. Squid-2.7 is old enough that it only understands HTTP/1.0
properly and some of HTTP/1.1. Its quite possible that "working" origin
connections are not using anything even remotely resembling HTTP/1.0.

Amos