Re: [squid-users] Authentication problem

On 4/04/2012 3:54 a.m., Mohamed Amine Kadimi wrote:
> OK, so here's another pseudo code that comes to my mind, this is
> somehow similar to some commercial products (Ironport, bluecoat):
>
> - The user connects to http://www.somesite.com <http://www.a.com/> via
> the proxy
> - The Proxy redirects to
> http://authenticationportal/http://www.somesite.com
> <http://authenticationportal/http://www.A.com> with 302 return code.
> - User is verified/authenticated on the authentication portal. This
> authentication portal sets a cookie and redirects to
> http://www.somesite.com <http://www.a.com/>
> - User connects to http://www.somesite.com <http://www.a.com/> via
> proxy. Proxy knows user is authenticated (cookie).
>
> The problem is with the last step since the cookie is bound to
> http://authenticationportal
> <http://authenticationportal/http://www.A.com> so the user may
> encounter an endless loop.

Exactly. The browser authenticated against your website. It did not
authenticate against the proxy or against "somesite.com".

The designed purpose of these redirect tricks in commercial proxies (and
Squid captive portals too) is to get the client to make a request to a
controlled web service. That server pulls details such as the cient IP
address and user-agent header (maybe other things) which the proxy can
use as the things it checks for in external_acl_type script to guess at
which later requests are coming from this same client and allow them
through. If you do login at that point (optional!) it is merely to
associate the browser signature with a username for recording/billing
purposes.
   Notice how there is nothing required for the browser to do except
visit. Basically: no authentication.

>
> Do you know the solution for letting this authenticated user go to the
> target after being authenticated

I think you are getting closer to understanding the boundary between
possible and impossible.

The whole point of traffic interception is that the browser is *not*
aware of the proxy. You might as well try to drink water out of an empty
cup, as to get the browser to do something special for the proxy.

I like your example. "somesite.com" happens to actually be a real
website owned by an actual dodgy company. Go on; visit it. See the ads,
see the script errors, read the no-privacy policy, notice how the
opt-out from their user tracking systems is not working.

Now consider what would happen if "authenticationportal" was your own
banks website. What details about your login to the bank would you want
to send to that dodgy website? the username? the password? the session
cookies? some other detail used to link you and your accounts?

You are asking us how to make the browser spread exactly those private
informations to websites which have no business receiving it.

Amos

>
> On 3/04/2012 3:40 a.m., Mohamed Amine Kadimi wrote:
>
> Dear Developpers and Community,
>
> I would like to set up the following configuration using squid:
>
> When a user asks for a web page he is transparently redirected to
> squid, where an authentication must be done before serving the
> user
> with content.
>
>
> Please read
> http://wiki.squid-cache.org/SquidFaq/InterceptionProxy#Why_can.27t_I_use_authentication_together_with_interception_proxying.3F
>
>
>
>
>
> However, users IP are being NATed before going to the proxy.
> So the
> solution would be to use an application-layer verification:
> cookies or
> http headers
>
> So, I come across the following solutions:
>
> 1. Use an ICAP server which checks if a cookie is set,
> otherwise set
> it for an authenticated user
> the problem is: cookies are bound to domains + each http
> request must
> be validated
>
> 2. Use a php splash page which sets the cookie then redirect
> to destination
> same problem as ICAP
>
> 3. using squid authentication and checking if Proxy-Authorization
> header is set before serving the client
> problem: sessions are associated to the IP by squid
>
> I'm using squid 3.1
>
> Thank you for any idea
>
>
> The whole point of transparent interception is that the browser is
> *completely unaware it is talking to a proxy*. It contacted some
> web server, and *all* of its communications are with that server.
> If you can find a way to trick it into storing security
> credentials of any kind set by your proxy it will consider those
> credentials safe to use when contacting the same server via other
> non-HTTP methods as well, causing great deal of problems. The good
> thing to do at that point is to report the zero-day security
> vulnerability you just found.
>
>
> You might be able to use details gleaned from the browsers request
> to *guess* what user it is and have a external_acl_type script
> inform Squid of the guessed username. Or the authorize (*not*
> authenticate) the request to happen.
>
> Amos
>
>
>
> --
> Mohamed Amine Kadimi
>
> Tél : +212 (0) 675 72 36 45
> <tel:%2B212%20%280%29%20675%2072%2036%2045>
>
>
Received on Wed Apr 04 2012 - 12:56:40 MDT