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

Well I have been trying to build for SLES 11 SP3 an rpm.
If you are not bound to the RPM format I can probably try to build you a
tar.gz file of a newer version that should run on your system.

Eliezer

On 07/03/2014 07:17 AM, Amos Jeffries wrote:
> 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:54:56 MDT