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

Reply via email to