On 2014-07-01 05:22, Robert Dahlem wrote:
Hi,
I'm having trouble with connection pinning. I'm on SUSE Linux
Enterprise
(SLES) 11 SP3, so I'm stuck with squid3-3.1.12-8.16.18.1 at the moment.
In which case you are also stuck with this broken pinning. If you are in
a position to accept patches then you are also in a position to custom
build a newer proxy version where its already fixed.
My scenario: Firefox, Squid and a parent proxy (McAfee Web Gateway).
The
parent proxy offers "Proxy-Authenticate: Negotiate" and
"Proxy-Authenticate: NTLM" to provide for single sign on. Firefox jumps
on "Negotiate" the first time but the parent proxy knows about
Firefox's
problem and offers only "NTLM" the next time.
What Firefox problem would that be?
This scenario has been working with Squid 2.7 for quite some time
(years
actually). Now I'm in the process of migrating to Squid 3.1.
The configuration condenses to:
http_port 8080
acl me src 1.2.3.4/32
http_access allow me
http_access deny all
cache_peer myparent.dmz.prv parent 8080 0 no-query \
no-digest login=PASS name=myparent.dmz.prv
Ah. login=PASS does not do what you think it does. In 3.1 it relays
*Basic authentication* credentials to the parent proxy.
Squid-3.2 or later provide the *login=PASSTHRU* option which relays the
NTLM handshake headers untouched to the parent.
cache_peer_access myparent.dmz.prv allow
always_direct deny all
never_direct allow all
I tried with "connection-auth=on" at "http_port" and "cache_peer" but
that did not help.
The name= clause seems redundant, it is an artifact of a local load
balancer configuration. I removed it to eliminate possible
interferences. Originally it was:
cache_peer 127.0.0.1 parent 8090 0 no-query \
no-digest login=PASS name=myparent.dmz.prv
I can see with tcpdump that Squid not even remotely maintains a 1:1
relationship between inbound and outbound TCP connections. Instead, it
seems to jump on the first free outbound connection for nearly every
incoming request. This reliably breaks the NTLM authentication scheme
and as a result password requests keep popping up in the browser.
This is correct HTTP behaviour. The issue is not that an existing
connection gets used randomly, but what happens to that connection after
NTLM starts. Also HTTP never has a fixed 1:1 relationship between
connections.
NTLM pinning requires only that the connection is used exclusively by
the authenticated client *after* the handshake. If Squid cannot pin it
to the one client then both inbound and outbound connections must be
torn down after the request and start from scratch authenticating
another set of connections for the next request.
Does this match what you are seeing?
I could probably resort to 2.7.STABLE5, which is delivered with SLES 11
SP3 too. But that seems to be the cowards way :-) and I still have some
time to do some tests before moving towards production.
If 2.7 works and you cant upgrade, then you are stuck.
I suggest re-evaluating the use of an OS (or internal policy) which
places this restriction on you.
Amos
