Re: Authentication problem

Amos Jeffries <squid3@xxxxxxxxxxxxx> · Thu, 05 Apr 2012 00:56:32 +1200

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>

Search squid archive
Re: Authentication problem
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]