[squid-users] Authorization header is overwritten with cache_peer credentials (tricky config or bug?)

Hi! I'm experiencing a strange behaviour with our Squid installation at work. The version is "Starting Squid Cache version 2.7.STABLE9 for x86_64-debian-linux-gnu..." according to cache.log. (Debian Linux 6.0.2) The scenario is the following: We're part of a corporate network where each user has to authenticate with his/her Active Directory password to the company-wide proxy server. However we have some special Windows machines that run with local accounts only. On these machines we run Antivirus software that need web access in order to get their updates, and it would be a great hassle to provide user passwords on these machine regularly, since all users are required to change their AD passwords every 90 days. To solve this we have setup a local Squid where we have manually configured the proxy password to use in the squid.conf file using a cache_peer entry for the upstream company-wide proxy. The Windows clients with local accounts are setup to use this local squid as their proxy. Then after 90 days when the password needs to be changed, we only need to update the squid.conf file, and all the 100+ machines with local accounts can still get their Antivirus updates So in short our local Squid is de-authenticating the web access for these local clients. So far so good, and it all works perfect for example for normal web browsing, including SSL. However the strange issue arises with one of the softwares, namely Nod 32 that needs to authenticate to the Eset server in order to retrieve the virus definition files. The Nod32 client uses a simple GET request with the Authorization header set to the login/password (encoded in base64). The problem is that Squid rewrites this Authorization header and replaces the login/password hash with the login/password used for the upstream cache_peer. The cache_peer authentication is provided in the Proxy-Authorization header, so replacing the contents also of the Authorization header with the same data definitely seems like a bug to me? Also, for testing purposes I've tried to use the header_replace statement in squid.conf to force the contents of the Authorization header to the proper login/password hash, but this doesn't work either. Squid still puts the same hash as for the Proxy-Authorization also in the Authorization header. This has all been verified by running Wireshark directly on the Squid server. Any help with this matter is greatly appreciated! Is this a bug or have I done a mistake somewhere? From squid.conf: cache_peer 10.23.3.5 parent  8080  0  no-query default originserver proxy-only no-digest login=<login>:<password> header_replace Authorization <HASH FROM NOD32 CREDENTIALS>   <- Only used temporarily for testing purposes. Wireshark shows the following when Nod32 tries to authenticate to the Eset server: Proxy-Authorization: Basic <HASH FROM cache_peer CREDENTIALS> Authorization: Basic <HASH FROM cache_peer CREDENTIALS> And of course it should look like this: Proxy-Authorization: Basic <HASH FROM cache_peer CREDENTIALS> Authorization: Basic <HASH FROM NOD32 CREDENTIALS> A final note: It has been confirmed that the Nod32 client sends the correct login/password hash by running Wireshark also directly on one of the Windows clients. /Leon
Received on Mon Sep 05 2011 - 14:14:42 MDT