The Story of secure user-authentication in squid

Question

once upon a time, there was a beautiful warm virtual-jungle in south america, and a squid server lived there. here is an perceptual image of the network:

                 <the Internet>
                        | 
                        | 
           A            |          B
Users <---------> [squid-Server] <---> [LDAP-Server] 

When the Users request access to the Internet, squid ask their name and passport, authenticate them by LDAP and if ldap approved them, then he granted them.

Everyone was happy until some sniffers stole passport in path between users and squid [path A]. This disaster happened because squid used Basic-Authentication method.

The people of jungle gathered to solve the problem. Some bunnies offered using NTLM of method. Snakes prefered Digest-Authentication while Kerberos recommended by trees.

After all, many solution offered by people of jungle and all was confused! The Lion decided to end the situation. He shouted the rules for solutions:

• Shall the solution be secure!
• Shall the solution work for most of browsers and softwares (e.g. download softwares)
• Shall the solution be simple and do not need other huge subsystem (like Samba server)
• Shall not the method depend on special domain. (e.g. Active Directory)

Then, a very resonable-comprehensive-clever solution offered by a monkey, making him the new king of the jungle!

can you guess what was the solution?

Tip: The path between squid and LDAP is protected by the lion, so the solution have not to secure it.

Note: sorry if the story is boring and messy, but most of it is real! =)

               /~\/~\/~\
            /\~/~\/~\/~\/~\
          ((/~\/~\/~\/~\/~\))
        (/~\/~\/~\/~\/~\/~\/~\)
       (////     ~   ~     \\\\)
       (\\\\(   (0) (0)   )////)
       (\\\\(   __\-/__   )////)
        (\\\(     /-\     )///)
         (\\\(  (""""")  )///)
          (\\\(  \^^^/  )///)
           (\\\(       )///)
             (\/~\/~\/~\/)         **
               (\/~\/~\/)        *####*
                |     |           ****
               /| | | |\            \\
            _/  | | | | \_ _________//   Thanks!
           (,,)(,,)_(,,)(,,)--------'

---

Update:

Massimo explained that the authenticating method between Users-squid and squid-LDAP does not have to be same. we can use arbitary method to get authentication information from users and arbitary method to authenticated gathered data.

But there is a problem: the input/output of all types of authenticators is not same. For example:

• a Basic authenticator should read "username password" pair in a line and reply a OK if user-pass is correct or ERR
• a Digest authenticator should read a username:realm and reply a hex-encoded of HA(A1) or an ERR.

Althought there is no direct relationship between client-squid method and squid-ldap method, the gathered data from client must be compatible with method used in squid-ldap part. Therefore, if we change authenticating method in users-side, we maybe should change our authenticator too.

So the problem simplifies to:

1. In first level, i (the monkey!) am looking for a good authentication method in user-side. Which method do you recommend which is secure and supported by most browsers? i am in confused between NTLM, Kerberos and Digest.

2. Where i can find an authenticator which supports credentials information of selected method and authenticates through LDAP.

Answer 1

One interesting feature that could help you here is that the method Squid uses to ask the client browser for authentication (path A) does not need at all to be related to the method it uses to actually validate the credentials supplied by the user (path B). This means, f.e., that you can make Squid "talk" NTLM with client browsers, but then it could very well validate users against Linux's internal user database (/etc/passwd). There is no need for credentials acquired using NTLM (on path A) to actually be validated against a Windows domain (on path B). The same applies to any possible combination of client-side authentication methods and server-side authentication ones.

What this means in your case, is that f.e. you can safely configure Squid to request NTLM authentication from client browsers instead of basic authentication, and this will not in any way require you to actually use Samba/WinBind/AD/whatever.

So you can choose whatever method you want for client-side authentication, yet still keep validating users against a LDAP server after they provided their credentials using the method you selected.

The magic happens, of course, in squid.conf:

#auth_param negotiate program <uncomment and complete this line to activate>
#auth_param negotiate children 5
#auth_param negotiate keep_alive on
#auth_param ntlm program <uncomment and complete this line to activate>
#auth_param ntlm children 5
#auth_param ntlm keep_alive on
#auth_param digest program <uncomment and complete this line>
#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
#auth_param basic program <uncomment and complete this line>
#auth_param basic children 5
#auth_param basic realm Squid proxy-caching web server
#auth_param basic credentialsttl 2 hours
#auth_param basic casesensitive off

Each auth_param directive enables a specific authentication for client browsers (path A), while the "program" part sets what Squid will actually use to validate the credentials provided by users. You can use whatever authenticator program you want here (even a custom-written one), as long as it can receive a user id and a password and answer "yes" or "no".

You just need to take whatever authenticator you're using to do your LDAP query and stick it into the "auth_param ntlm" or "auth_param digest" statements, instead of the "auth_param basic" one where it is now.

---

Update:

You should definitely use squid_ldap_auth as your authenticator, but I can't tell you exactly how without any detail about the specific LDAP server you're using.

Regarding client-side authentication, any one should be good; I'm quite happy with NTLM, and most browsers support it nowadays.

Such a configuration would look like this in squid.conf:

auth_param ntlm program /usr/lib/squid/squid_ldap_auth <parameters>

This will ask for user credentials (path A) using NTLM, then validate them against a LDAP server (path B); but those "parameters" strictly depend on your LDAP implementation and configuration.

This could help, too: http://www.cyberciti.biz/tips/howto-configure-squid-ldap-authentication.html.

Answer 2

Kerberos is not an option for HTTP authentication. NTLM is not well supported in any browser other than IE. Basic is not secure unless you put it behind HTTPS which AFAIK squid cannot do. So you are left with Digest.