If you use authentication in squid you have several mechanisms ( authenticators ) to chose from. The Basic authenticator is the easiest to set up and the most insecure because the client sends the username and password in plain text to the proxy server.

Instead of using the basic you would consider using the digest authenticator. This authenticator does not require the client to send the user and password in plain text but encoded in an MD5 hash so that an attacker that captures the data between the client and proxy server will not be able to use the user and password.

To use the digest authenticator you have to specifically compile it if you are compiling squid from sources. Before you compile just add --enable-auth="basic digest" to the ./configure line or after you compile squid, go to helpers/digest_auth/ and do :

make make install

If you are using Fedora then the digest authenticator is already compiled and the program is located at /usr/lib/squid/digest_pw_auth

If you are using squid from ports on freebsd then the program will be compiled by default and installed at /usr/local/libexec/squid/digest_pw_auth

If you emerge squid on gentoo the program will be compiled by default and installed at /usr/libexec/squid/digest_pw_auth

Now for the configuration part the default squid.conf gives almost all the info we need. I say almost because it does not say much about the format of the file where you have to store the passwords:

#"program" cmdline # Specify the command for the external authenticator. Such a program # reads a line containing "username":"realm" and replies with the # appropriate H(A1) value hex encoded or ERR if the user (or his H(A1) # hash) does not exists. See RFC 2616 for the definition of H(A1). # "ERR" responses may optionally be followed by a error description # available as %m in the returned error page.

I did not want to read the whole RFC 2616 just to find the definition of H(A1) so I looked in squid source at digest_pw_auth.c right in the header :

* To avoid storing a plaintext * password you can calculate MD5(username:realm:password) when the * user changes their password, and store the tuple username:realm:HA1. * then find the matching username:realm when squid asks for the * HA1.

Storing encrypted ( hashed ) passwords will not really help the security that much, the part that helps security is that plain text passwords are not sent over the net, but we will store encrypted passwords anyway. HA1 is really just MD5(username:realm:password) and you have to pass the "-c" parameter to digest_pw_auth if you want to not store the plain text passwords in the file and the format to be username:realm:HA1.

I have not tested this on IE on windows, because I almost never use windows or IE. If it asks for your password all the time and no connection the the actual site you are trying to access works then it’s most likely an authentication problem. Maybe your version of IE does not support digest authentication and in this case you should use basic authentication.

We have Squid3 working well checking against AD but need to add some Guest accounts. We don’t want these to be in AD at all and so I thought the digest file may be the easiest way around this but then hit a major issue; I can’t get AD authentication and digest authentication to work together – only one seems to work ignoring the other.

maybe you can do it by replacing the default digest program with another authentication program. One that would verify some users against your LDAP server and others against some other password file like those used by the standard digest auth.