Re: [squid-users] Connection pinning in Squid 3.1

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
Received on Thu Jul 03 2014 - 04:18:09 MDT