Search squid archive

Re: Authentication problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 <> via the proxy - The Proxy redirects to http://authenticationportal/ <http://authenticationportal/> with 302 return code. - User is verified/authenticated on the authentication portal. This authentication portal sets a cookie and redirects to <> - User connects to <> 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/> so the user may encounter an endless loop.

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

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. "" 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.


    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
        with content.

    Please read

        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.


Mohamed Amine Kadimi

Té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]

  Powered by Linux