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

Amos,

Thanks for the reply.
I have compiled the latest Squid version 3.2.0.11 and moved up my 'auth_param' above acl. I do not get the error mentioned in first email.
When I run 'squid -k reconfigure' squid runs fine but seems to let the connection anyhow from all clients without requesting credentials.

Kind Regards,

ZS

-----Original Message-----
From: Amos Jeffries [mailto:squid3_at_treenet.co.nz]
Sent: 06 September 2011 00:32
To: squid-users_at_squid-cache.org
Subject: Re: [squid-users] Authorization header is overwritten with cache_peer credentials (tricky config or bug?)

 On Mon, 5 Sep 2011 07:14:35 -0700 (PDT), Leon - wrote:
> 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.

 Problem #1: allowing users to self-authenticate (their machine is both originating credentials and acting as the verifier DC to check that they are correct). This is a very weak link in the security layers. This undermines most of the security benefit of the 90-day password rotation.
 Attackers don't have to guess passwords, they just use one of these machines.

>
> 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.

 There is no "de-" about it. The Squid is automatically _upgrade_ authenticating anyone who can connect to it. Just like you configured to happen. As long as you understand that the login used by this Squid box is extremely vulnerable to attack and being used by unwanted visitors.
 You can (and should) configure the higher security area where everything is on the DC to treat it carefully.

 (sorry if you know the above already, adding it mostly for others reading this).

>
> 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.
>
 <snip>
>
>
> 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>

 Nod32 is logging into the Squid. Which it knows is a proxy.

>
> 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.

 Your cache_peer is both an originserver AND required to get a static pair of login credentials. Proxy authentication is not part of the origin formatted HTTP syntax, so can't be sent and work with origin servers. The only way the required login credentials can be sent is via
 WWW-Auth* headers.

 If the Nod32 box is a proxy, remove the "originserver" traffic type flag.

 If the Nod32 box needs the www-auth credentials sent by the client app, remove login= entirely or replace with "login=PASS" (exact text).

 Also, the "default" flag means that peer can be used as a backup
 pathway to the Internet. This clashes with the meaning of originserver
 which flags it as an individual "dead end" / web server data source.

 Amos
Received on Tue Sep 06 2011 - 22:14:35 MDT