Can Squid edit credentials before passing them through?

April 25, 2012 11:14 PM

How can I make Squid modify the credentials it passes to an upstream proxy?

At the school I netadmin, I have a Squid web proxy on the school LAN, configured to chain to an upstream proxy using

cache_peer proxy.oursubdomain.example.com parent 3128 0 no-query no-digest no-netdb-exchange login=PASS

Upstream is in the process of cutting over from using its own web proxy to using zscaler.com instead. Migrating all the existing user accounts is easily done in bulk; no problem there. But because zscaler is a shared service, its usernames are formatted like email addresses, so instead of sending usernames like flabdablet to upstream's proxy, I will need to send usernames like [e-mail] to gateway.zscaler.net.

I would rather not make my users type all that stuff every time they start up a browser. I would rather they didn't even notice the cutover when it happens. So I would like to tell my local Squid to append @oursubdomain.example.com to any username it collects from a user's browser before passing the username and password along to gateway.zscaler.net.

How can I do that?

posted by flabdablet to Computers & Internet (2 answers total)

I took a look at the documention for the cache_peer configuration directive and the Squid 3.1.19 source code. I thought using something like login=*%40oursubdomain.example.com in cache_peer would work, but looking at the source it appears that would result in a proxy authentication header like "Basic [e-mail]" (i.e. no password will be supplied to the proxy, not even the original supplied by the user).

To do what you want I think you'll have to make a custom build of Squid. I think you can get away with just having to modify HttpStateData::httpBuildRequestHeader() in http.cc. As a quick hack, you might try replacing the two lines that look like the following...

snprintf(loginbuf, sizeof(loginbuf), "%s%s", username, orig_request->peer_login + 1)

...with...

snprintf(loginbuf, sizeof(loginbuf), "%s%s:" SQUIDSTRINGPH, 
    username, orig_request->peer_login + 1, SQUIDSTRINGPRINT(orig_request->extacl_passwd))

I haven't tried it myself, so you should definitely look over the code yourself. That hack hopefully replaces the current login=*optional_suffix:password authentication option. Instead of sending a (possibly modified) username and fixed password to the upstream cache, it will instead send a (possibly modified) username and pass through the user supplied password. So, following that change, using login=*%40oursubdomain.example.com in cache_peer should do what you want (but the traditional login=*:password functionality will no longer be available). If the hack works, I recommend you replace the hack with legitimate code that handles both cases.
posted by RichardP at 2:04 AM on April 26, 2012

Response by poster: OK, so it looks like the provision that Squid makes for my use case is the login=*:password option to the cache_peer option, where it passes along a username collected from the user, accompanied by a fixed password. I'm not instantly keen to make, maintain and document a custom build, and the documentation says I can add extra stuff after the *, so I think I'll see what I can do with login=*%40oursubdomain.example.com:seekrit-zscaler-password in conjunction with a local user database, so users will actually need to authenticate (with individual local passwords) against the local Squid before it even thinks about passing their identites upstream.
posted by flabdablet at 3:23 AM on April 26, 2012