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.

Solution 1

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.

Solution 2

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.

Comments

[Massimo]

+1, totally awesome storytelling.

[user1364702]

should all questions be asked in this form?

[Massimo]

@Bart, probably not, but it's awesome anyway :-)

[Massimo]

@Isaac, I understood from your storytelling that LDAP authentication was already in place server-side, but your problem was the use of basic authentication client-side. Is this the case, or do you neet do set up LDAP authentication, too?

[Oskar Duveborn]

I'm a bit disappointed that the lion wasn't correctly syntax highlighted :7

[Massimo]

@Isaac, also keep in mind that, even if you use "standard" LDAP, your authentication will never be completely independent from the specific LDAP implementation you're using. The LDAP tree structure and the attributes to look up will definitely vary.

[Isaac]

@Massimo: currently i am authenticating users by Basic authentication through an LDAP server. Now i want to switch to more secure method for authentication. But just changing the authentication method is not enough since the provided credentials by user also changes and i've to use another authenticator. am i right?

[Massimo]

@Isaac, can you post the relevant lines of your squid.conf? By "authenticator", I mean "the part after <program> in your <auth_param> directive"; that's the executable program which actually validates user credentials.

[Isaac]

@Massimo, so true! Another problem we will have to deal with is how i should store passowrds in LDAP that be useful for the authenticator. for example storing just HA(A!) is not a good idea because it is only compatible with Digest. maybe storing password in multiple formats is a better solution.

[Isaac]

seems true! then which method do you offer? NTLM? Kerberos? which of them is supported on most browsers and already has a 'authenticator' which support ldap?

[Massimo]

@Isaac, please read better :-) There's no relationship between the method and the authenticator program, so, as long as you have an authenticator program that supports LDAP, you can use it with any client authentication method you like. And I was under the impressione you already are using it with basic authentication... isn't it so? Can you post the relavant portion of your squid.conf?

[Isaac]

Thanks. i explained this in Update section in the question. i Hope i am not wrong! :-/

[Isaac]

Now i'm authenticating users by HTTP Digest Authentication implemeneted by digest_ldap_auth (comes with squid) against the LDAP server.

[user1686]

HTTP does support Kerberos through the Negotiate mechanism; I've successfully used it with Apache and Squid. SSL is also an option for Squid, only Debian does not enable it due to license issues.

[Castro Roy]

I know this is an old post, but, using auth_param ntlm program /usr/lib/squid/squid_ldap_auth <parameters> doesn't work for me, squid crash and get restarted every time a user try to authenticate. Maybe because using the wrong parameters, but i'm using the same parameters with basic and works ok. Any ideas?