Can Squid help me work around broken web clients?

July 12, 2010 2:00 AM

Can I configure Squid to pass preset authentication credentials to an upstream proxy for a given set of websites without asking the client for them?

I'm a part-time school netadmin, and a Squid n00b.

The school can only get web access via an upstream Squid proxy I don't control, though I can create user accounts whose credentials it will accept.

There are various apps I'd like to deploy that require web access to their mother ships. All have some method for specifying a proxy server, but several (notably from Microsoft - grrr!) don't have any provision for presetting or prompting for proxy authorization credentials.

If I deploy a local Squid on my side of the firewall, I believe there's a way to tell it that the upstream Squid is its parent. What I'd also like to do is configure my local Squid with appropriate credentials to pass upstream whenever a client makes a non-authenticated request for one of several specified sites.

In other words: I'd like the local Squid to translate non-authenticated requests from clients to authenticated requests to its parent, but only on certain selected web sites.

Can this be done? If so, how?

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

Best answer: interesting... I'm guessing (and don't have easy access to a cache to try it out) but I reckon this can be faked out well enough...

what I'd try is making a bunch of aliases in your proxy's /etc/hosts file that all point to your parent cache in addition to its real dns name... say dumbapp1-cache.example.com and dumbapp2-cache.example.com in addition to cache.example.com... then configure dumbapp1-cache.example.com and dumbapp2-cache.example.com as additional cache_peer entries with the login=user:password option, even though they're all the same actual parent, and use cache_peer_domain to restrict which of the virtual parents (with what hardwired proxy-auth credentials) is used for which client requests...

actually, that allows anyone to make requests to these motherships, so you might be better using cache_peer_access to restrict the free credentials based on both source and destination...

hmmm... not sure I *like* this suggestion, but I reckon it'll work...
posted by russm at 6:01 AM on July 12, 2010

hmmm... and if you try that you should probably also use the hosts_file directive to keep the lies segregated from your system's main dns resolver...
posted by russm at 6:07 AM on July 12, 2010

Response by poster: Allowing anybody to make mothership requests is kind of inherent in the fact that these broken clients (which will be running on student workstations) don't ever supply credentials, so that's OK. What I want to avoid is the situation where anybody can simply point a browser at my local proxy instead of the official upstream one, and request any website they like using credentials stored in the local proxy instead of supplying their own.

Thanks, I'll try what you've suggested.
posted by flabdablet at 7:06 AM on July 12, 2010

Response by poster: It's working very nicely.

I added the following to squid.conf:

cache_peer proxy1.curric.local parent 3128 0 no-query no-digest no-netdb-exchange login=PASS
cache_peer proxy2.curric.local parent 3128 0 no-query no-digest no-netdb-exchange login=squid:wr96x9r0d6

acl auto_auth dstdomain .metafilter.com
acl auto_auth dstdomain .google.com
cache_peer_access proxy1.curric.local allow !auto_auth
cache_peer_access proxy1.curric.local deny all
cache_peer_access proxy2.curric.local allow auto_auth
cache_peer_access proxy2.curric.local deny all

I also added CNAME records to the curric.local DNS server to alias both proxy1.curric.local and proxy2.curric.local to the upstream proxy, and an A record pointing proxy.curric.local to the local Squid box, and fooled about a bit with always_direct and never_direct to stop proxy.curric.local ever attempting to connect directly to external sites.

A browser configured to use proxy.curric.local can now use Metafilter or Google without asking for credentials but will prompt for them for any other site, and assorted Wireshark traces reveal that proxy.curric.local is behaving exactly as I'd hoped it would.

Thanks, russm!
posted by flabdablet at 2:27 AM on July 13, 2010

no worries... faking configuration domains with DNS and lies isn't exactly elegant, but a quick scan through the squid docs today didn't turn up anything better... :)
posted by russm at 3:17 AM on July 13, 2010

now if only you were this handy on email security protocols...
posted by wilful at 11:07 PM on July 13, 2010

ah, wil, but this just required a bit of thinking and then banging out those thoughts out on my phone... making a modern imap server talk to a "feature-poor" client, on the other hand, needed actual effort and debugging... :)
posted by russm at 1:50 AM on July 14, 2010