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>
