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.
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.
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 KadimiTél : +212 (0) 675 72 36 45 <tel:%2B212%20%280%29%20675%2072%2036%2045>
[Linux Audio Users] [Photo] [Yosemite News] [Samba] [Video Projectors] [Video Devices] [Big List of Linux Books] [LCD TVs] [Webcams] [Linux USB]