- From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
- Date: Tue, 3 Dec 2013 12:49:04 +0100
- To: "Willy Tarreau" <w@1wt.eu>
- Cc: "William Chan (?????????)" <willchan@chromium.org>, "HTTP Working Group" <ietf-http-wg@w3.org>
Le Mar 3 décembre 2013 12:18, Willy Tarreau a écrit : > What happens is that in order to avoid credentials to pass in clear, the > proxy first gets your request. It sees it doesn't contain a specific > cookie, > so it responds with a 302 to an https login page. You enter your > login/passwd > there (there are variants with http pop-up and 401 but that's the same). > Then > in response it gives you a URL pointing to the original site and an > argument > in the query string to identify you. Your browser then follows this second > redirect, the proxy detects the argument and sends you a cookie in > response > with a redirect to the original URL. Then your browser finally goes to > that > URL with the cookie delivered by the proxy. We have basically the same setup except with 307, no cookie and timeout (a successful auth authorises the whole ip for some time, which is less secure but permits using a browser to unblock naïve http clients). Works fine in ie when you disable the https redirect blocking. The browser is aware of the proxy (via pacfiles) but not for auth purpose as, like Willy stated, standard proxy auth is unsecure and we do not wish for it to be intercepted inside our networks (huge imperfectly secured internal networks) Cheers, -- Nicolas Mailhot
Received on Tuesday, 3 December 2013 11:49:33 UTC