Search squid archive

Re: RE: Diffence between NTLM in 2.6 compared to 3.3.5 - Citrix ?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 31/05/2013 12:24 p.m., Kris Glynn wrote:
-----Original Message-----
From: Kris Glynn
Sent: Wednesday, 29 May 2013 1:07 PM
To: squid-users@xxxxxxxxxxxxxxx
Subject: Diffence between NTLM in 2.6 compared to 3.3.5 - Citrix ?

I've noticed that since upgrading from Squid 2.6 to Squid 3.3.5 the Citrix ICA Client will no longer authenticate via NTLM to squid 3.3.5 - the ICA client just keeps popping up asking for NTLM auth - at no stage does it fallback to basic auth.

Every other NTLM aware application whether it be IE, Firefox, Chrome and even curl works fine and can authenticate no problems via NTLM however the Citrix ICA client just won't work.

If I change back to squid 2.6 it works fine. Both are using exactly the same squid.conf with...

# Pure NTLM Auth - fallback
auth_param ntlm program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp
auth_param ntlm children 60 startup=15 idle=10 auth_param ntlm keep_alive off

# BASIC Auth - fallback
auth_param basic program /usr/bin/ntlm_auth --helper-protocol=squid-2.5-basic auth_param basic children 10 auth_param basic realm Internet Access auth_param basic credentialsttl 1 hours

Has anyone else experienced this?
To answer my own question it was due to Citrix ICA Client (I'm using 13.4.0 - latest version) ignoring "Connection: keep-alive" headers in squid 3.3.x and starting new connection breaking the NTLM auth challenge.

Squid 2.6.x sends "Proxy-Connection: keep-alive" with NTLM auth responses which is the only header the Citrix ICA Client appears to accept to maintain keepalive.

What RFC can I point Citrix at so I can submit a bug with them to fix their client and accept both headers? Am I correct in saying that Squid 2.6 is a HTTP/1.0 proxy and 3.x are HTTP/1.1 proxies?

You can point them at RFC 2616...

in section 8.1.2 on how persistence is controlled:

"
   Persistent connections provide a mechanism by which a client and a
   server can signal the close of a TCP connection. This signaling takes
   place using the Connection header field (section 14.10).
"

in section 8.1.3 on what proxies are required to do:

"
   It is especially important that proxies correctly implement the
   properties of the Connection header field as specified in section
   14.10.
"

note this section 8.1.3 requirement means following a non-standard Proxy-Connection and ignoring the mandatory Connection is a violation and will cause problems when they differ.

Here is another good explanation of what is wrong with it:
http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/web-proxy-connection-header.html


There is a myth floating around that 2.6 etc do not obey Connection properly. That is not entirely true. They only have problems when Proxy-Connection is delivered and/or the Connection header is omitted entirely. The newer squid have better handling, but to be conservative sending it explicitly when contacting a proxy appears to be the best choice.

Amos




[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux