Jul 232012

I’ve had a bunch of questions on my Squid LDAP transparent proxy authentication script script about whether or not it was possible to use cookies in Squid proxy authentication with a transparent proxy. The answer to this question that I’ve found by doing research and by my own deductive reasoning, is no.

Before we go into more detail about why, let’s first remind ourselves why you can’t use authentication when using a transparent/interception proxy in Squid. Or to reiterate the article, since the user’s browser is not expecting there to be an authentication and it would be a huge security issue for the browser decided to just start sending authentication information to any intercepting programs when the user has not told it to do so. I do not think that this will ever become possible.

So, to get around this we invented the IP based authentication solution. What the script I have written (with parts borrowed from other people and for this please consult the references) is display a custom web page that is served by apache that handles the authentication using HTML forms and POST variables. Squid does not handle any authentication and the browser is not bothered by stuff it does not need to be concerned with.

On the Squid side, another custom script comes into play. That script is passed the IP of the user trying to access and that IP is then referenced in the MySQL database that stores the authenticated IP addresses. If there is a hit it returns success. Otherwise, the user is denied.

This is a rather simplified solution. However, there is one flaw: this is an IP based solution. This means that if you have a bunch of users logging in to just one machine with just one IP once one user authenticates, every user using the machine now has the same access. This could be a problem.

I looked in the external_acl_type in the squid.conf file to see if there were any other useful variables that could be passed to a custom script to allow us to get around this issue. What I did find is that it allows you to look up headers using %<{Hdr:member} and %<{Hdr:;member}. This means that, yes, Squid can get cookies that are saved on the user’s browser.

However, the fatal drawback, or rather wonderful security goodness about cookies is that they all have a domain variable set. This means that the browser can only send that cookie to a specific domain (consult RFC2109 for more info). Since in most cases it’s not feasible to set a cookie for every single possible domain a user will access, the cookie method is not going to work for transparent authentication.

Another drawback is that other programs such as Windows Update or any other software will not have knowledge of the cookie you have in your browser. Thus even having a cookie that grants access to all web pages that may work for your Mozilla Firefox browser, it would not then work for your software that updates Windows or your IM software that can’t connect to its IM server.

In conclusion, I think IP based authentication is the best way to go for transparent authentication. Your mileage may vary. If it does I’d love to hear about it.

  5 Responses to “Is Squid transparent proxy auth with cookies possible?”

  1. well stated. I’ve finally gone to explicit proxy. Not as bad as I thought, there is even a GPO that auto configures firefox.

  2. So the question is, how is it that Smoothwall SWG, Bluecoat, Barracuda, Websense, Cisco, etc, can all perform Transparent Authentication against AD/etc, when configured in Transparent Proxy Mode? I’ve used most of these products and although you may get prompted for credentials via a popup or login page, the authentication when in transparent/gateway mode does work. It’s one thing for SQUID Devs to say, “We can’t support this functionality.” But it’s another thing altogether to assert that it’s simply not possible and that nobody should even try – which is obviously false as it’s already being done in instances where browsers aren’t sending credentials.It’s frustrating how short-sighted and geek-embracing the OpenSource Community can be at times.

    • I think they aren’t really using proxy authentication, they either redirect to an “Intercept Login Page” or redirect to a site that sends a request for digest or basic authentication which isn’t the same as proxy digest/basic authentication. Not sure if they are just authenticating the IP or doing the cookie trick above or something else. Just thinking out loud.

      That’s what I gather from this bluecoat KB:

      I don’t see why that can’t be implement on squid with an external_acl.

      • Hi Daniel,
        You’re spot on; it’s definitely not true proxy authentication, but rather an intercept/redirection where cookie tracking is implemented. On the platforms I’ve used this type of authentication/tracking is either performed via cookies and/or IP tracking on GET requests. I don’t think it’s possible to do true auth, but interception and then tracking via cookies is definitely possible, and I feature that I really wish was available in Squid – or at a minimum I wish they wouldn’t dissuade folks from trying to come up with a solution.

        Michael’s IP authentication is definitely a good solution, but it wont work for many of us where NATs/VDI/Terminal Servers are in play.


  3. As Mike suggests, I think the cookies method could be fully implemented with the external ACL type even without any more attention from squid developers. Yes, it would mean dropping a session cookie for every single domain. Though it sounds tacky, is there a specific reason this *can’t* be done? It may not be elegant but neither is say the NTLM auth protocol. But I digress…
    In response to the other point Mike makes about windows update, in most environments we end up white listing updates servers so they proceed without authentication so that’s really not a major issue. As a matter of fact even with explicit proxy this is a problem since windows update refuses to perform proxy auth.

    I guess what I’m saying is, Let’s try this..

I love it when you comment!

%d bloggers like this: