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 :
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:
# 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
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.
The final configuration for the digest authenticator :
auth_param digest program /usr/lib/squid/digest_pw_auth -c /etc/squid/digest_passwd
auth_param digest children 5
auth_param digest realm Squid proxy-caching web server
auth_param digest nonce_garbage_interval 5 minutes
auth_param digest nonce_max_duration 30 minutes
auth_param digest nonce_max_count 50
I created a small script to help me add users to /etc/squid/digest_passwd :
- span style="color: #ff0000;">"$1" -o -z "$2" -o -z "$3""Usage: $0 user password 'realm'""$user:$realm:$pass"' '"$user:$realm:$ha1"
To add a user named test with the password 1234 to the file specified in our config I would just do :
./digest_user.sh test 1234 'Squid proxy-caching web server' >>/etc/squid/digest_passwd
Now all that's left to do is to set up the proper acls and http_access directives to allow the authenticated users to use the proxy server. I'm using this acl to match any user that can authenticate:
acl authenticated proxy_auth REQUIRED
And then this http_access directive before any other http_access directive:
http_access allow authenticated
11 thoughts on “squid digest authentication”
In your implementation , the windows machines with IE, work fine ?
my IE’s ask for password all time ….
Thats a bug with IE, it doesn’t support RFC2617.
It only supports BASIC authentication.
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.
Is this working on firefox? If it is then it’s clearly an IE problem.
acl authenticated proxy_pass REQUIRED
proxy_pass” should be
You are right, thanks for the note. I have corrected the post
can you mix this digest method with AD authentication as well?
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.
Any help would be appreciated – Cheers.
maybe if you create separate acls for AD and digest users. It’s just an idea, I never used AD so I can’t give you a working solution.
The separate acls is the issue – I’m only aware of refering to auth_param with proxy_auth (eg acl users proxy_auth REQUIRED).
If I used 2 methods I’m not aware of any way to separate the proxy_auth to different acls.
I have a feeling that this isn’t possible (mixing auth_param methods – LDAP and Digest).
Thanks for your help
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.
I’ve looked at using one of the scripts to combine authentication methods but so far no luck.
I’ll keep looking.