Re: [squid-users] transparent proxy with authentication

On Monday 24 October 2005 20:44, Chin Kah Yi wrote:
> Thanks Merton for explaning.
>
> What if the design is changed from wccp to a redirection level7 switch
> such as foundry serveriron? L7 switch redirect http traffic to squids.
> Will this be able to design provide authentication from squid?
>
> If transparent squid cant provide authentication due to the
> complications, would you recommend we get all users to enter proxy IP at
> their own browser before they can browse, so that authentication can
> still be provided? If there is a proxy pool (a few proxies for
> redundancy), then I may use a L7 content switch to provide a virtual
> proxy IP for all user browser to point to, then the content switch will
> route the user to the least loaded squid. All squid will definitely be
> now be authenticating users against the Sun Ldap server.

My personal preference is to use a defined HTTP proxy server. Although there
was some initial concern about taking this approach, my customers have become
convinced that this is the best approach. Well, most of them have. :-)

One key feature of an HTTP proxy server over an HTTP intercept proxy is that
all HTTP traffic is passed to the HTTP proxy server regardless of port used.
The HTTP intercept proxy only addresses activity on port 80 or any additional
ports that you specify.

Several of my customers were concerned about employees accessing pornography.
It was clear from analysing network traffic that the HTTP intercept proxies
that they had been using were missing some of this activity because port 80
was not being used.

There are several ways of configuring your network to use an HTTP proxy
server.

   (1) Manual configuration of the HTTP proxy server.
   (2) Manual configuration of an automatic configuration file.
   (3) Configuring your network for Web Proxy Automatic Detection.
   (4) Configuring your DHCP server to support automatic configuration.

I use all of the above. A problem with (1) is that it is not robust. If the
HTTP proxy server fails, web content is inaccessible. This can be solved by
using a L7 switch as you suggest. A secondary problem with (1) is that it
doesn't allow you to use different HTTP proxy servers that could be used to
implement strategic solutions, i.e. balancing the traffic between multiple
service providers.

I like options (2), (3), and (4). I can create an automatic configuration
file, proxy.pac, that identifies how to access web content based on where the
HTTP server is located. Is the HTTP server connected to our local network?
Go direct. Is it connected to our corporate WAN? Go to the intranet HTTP
proxy server. Is it an external HTTP server? Go to the Internet HTTP proxy
server.

Web Proxy Automatic Detection was a great idea introduced by Microsoft. All
you needed to do was to define a CNAME wpad.local.domain.com that pointed to
a web server containing a file wpad.dat. The latter was nothing more than a
symlink to proxy.pac. Linux and Mac OS X support automatic detection and I
think most of the BSD systems, as well.

Unfortunately, Microsoft broke this in one of the service packs to Windows
2000. Fixed by providing two additional symlinks: proxy.pa and wpad.da that
point to proxy.pac. With WindowsXP, Microsoft screwed it up further, you
need to use (4) and define DHCP Option 252 to pass a URL to the DHCP client
that defines the location of the proxy.pac file.

If you have management support to block port 80 to all but the HTTP proxy
servers, use all of the above techniques to capture all your HTTP traffic.

Merton Campbell Crockett

Ps: As you can note, I have a definite bias. For political reasons, I was
     recently moved from Engineering to IT. IT doesn't quite share my views.
     A few of them are, finally, understanding that you don't need to touch
     each and every system.

>
> I understand that servers may be affected by this. However, I could set
> at firewall that only IP at Server Farm can have http direct to
> internet, bypassing proxies.
>
> To prevent users from going directly to Internet, firewall will block
> their IP from http access direct to internet.
>
> The objective of this is to enable logging of login with url accesses on
> shared computers. Such computers are like those in computer labs where
> anyone can use to access to internet. If you do have alternative control
> mechanism, please advise.
>
> Thanks again.
>
> Kah Yi
>
> -------- Original Message --------
> From: Merton Campbell Crockett <mcc@CATO.GD-AIS.COM>
> To: squid-users@squid-cache.org
> Subject: Re:[squid-users] transparent proxy with authentication
> Date: 25/10/2005 10:47
>
> > On Monday 24 October 2005 18:36, Chin Kah Yi wrote:
> >>Dearest squid expert out there,
> >>
> >>Don't mind me being asking again - but why was authentication designed
> >>not to work with wccp? If transparent proxy design is required together
> >>with authentication, is there any alternative I could work on?
> >
> > With WCCP you are intercepting the HTTP request from the HTTP client.
> > The HTTP client assumes that it is communicating with the HTTP server.
> > If the HTTP intercept proxy were to request authentication, you would
> > have one of the following problems.
> >
> > (1) The HTTP client would present the credentials that it saved from
> > the last time that it accessed the HTTP server to the HTTP intercept
> > proxy. These credentials would fail the authentication tests and
> > access would be denied.
> > (2) If the HTTP client did not have any credentials saved, the user
> > would present the credentials requested by the HTTP intercept proxy. The
> > HTTP client would save the authenticated credentials. If the HTTP server
> > does not require authentication, there is no problem.
> > (3) If the HTTP server requires authentication, the HTTP client would
> > present the credentials required by the HTTP intercept proxy. The
> > authentication would fail and the HTTP client would be prompted to
> > provide new credentials.
> >
> > Obviously, this leads to a condition where the HTTP client needs to
> > supply multiple credentials on every access. It is important to note
> > that not all HTTP clients are browsers (Firefox, Internet Explorer,
> > Netscape, Safari, etc.). Many are applications or services such as AIM,
> > Jabber, Real Audio, etc.
> >
> > It might be possible to implement authentication in an HTTP intercept
> > proxy were realms consistently used and understood by all HTTP clients
> > and servers. However, the last time that I looked at this problem (ca.
> > 1999), I discovered that while HTTP clients tended to deal with realms
> > correctly there was a wide variance in the way realms were implemented in
> > HTTP servers with Microsoft IIS being the biggest problem.
> >
> > Merton Campbell Crockett

-- 
BEGIN:				vcard
VERSION:			3.0
FN:				Merton Campbell Crockett
ORG:				General Dynamics Advanced Information Systems;
				Intelligence and Exploitation Systems
N:				Crockett;Merton;Campbell
EMAIL;TYPE=internet:		mcc@CATO.GD-AIS.COM
TEL;TYPE=work,voice,msg,pref:	+1(805)497-5045
TEL;TYPE=work,fax:		+1(805)497-5050
TEL;TYPE=cell,voice,msg:	+1(805)377-6762
END:				vcard