Re: What will incentivize deployment of explicit proxies?

On Tue, Dec 3, 2013 at 3:18 AM, Willy Tarreau <w@1wt.eu> wrote:

> Hi William,
>
> On Tue, Dec 03, 2013 at 03:03:02AM -0800, William Chan (?????????) wrote:
> > > There are several use cases. First, explicit proxies commonly require
> > > authentication. This cannot be *cleanly* done using MITM, you generally
> > > have to hack with cookies and redirects, and it's often not compatible
> > > with a number of browser plug-ins or even software updates.
> > >
> >
> > Sorry, I'm having difficulty understanding this case. Can you explain
> > further? Just to be clear, what I was describing above was a transition
> > process.
>
> Yes of course, no problem.
>
> > I tried to highlight known existing proxy deployments and tried to
> > see how the new proposals would fit in. Can you explain what this use
> case
> > you're describing is more precisely, how it's solved (perhaps poorly!)
> > today, and how one of the new proposals have the appropriate incentives
> > from the various players to adopt it? When you say requires
> authentication,
> > to me that is a configured proxy that a browser is already aware of.
>
> The issue is that currently we don't have the ability to use proxies over
> TLS. So in places where using the proxy requires some authentication, it
> is not acceptable to pass proxy credentials in clear text. Thus you have
> the awful dance consisting in redirecting to the auth URL, and assigning
> a cookie for the site being visited. The same awful mechanism is usable
> for both explicit and intercepting proxies since the proxy auth is not
> used at all there.
>
> Standard proxy authentication (where the browser is aware of the proxy's
> presence and sends the credentials with all requests) is clean and reliable
> and totally avoids the issue above, but provides no confidentiality.
>

Gotcha. So Chromium supports HTTPS proxies today via PAC scripts. Please
see http://www.chromium.org/developers/design-documents/secure-web-proxy. I
think it could be improved. I think standardizing something for configuring
an HTTPS proxy would be cool. If that's what people mean by "explicit"
proxies, at least from my standpoint, it seems like the confidentiality
wins for both the browser and the proxy are clear.


>
> > If
> > it's already configured, then the browser already has the functionality
> to
> > talk to it, and the client administrator already has the power to
> configure
> > the client browser to speak to the proxy, and could already install MITM
> > certs (which I assume is what happens today).
>
> Yes but here I'm only talking about user authentication which already is a
> problem and is slowing down adoption of external proxies as well.
>

Gotcha, OK.


>
> > I suspect I got something
> > wrong in that understanding, so please correct me. I'm trying to
> understand
> > what would motivate an administrator who already has control over the
> > client devices and the proxy deployment to want to switch to an explicit
> > proxy instead.
>
> Again, intercepting proxies cause a lot of trouble. I've been running an
> obsolete flash plugin in Firefox 3.6 under windows in a corporate
> environment
> just because I couldn't upgrade it there. Upon every start it said "your
> version is obsolete, please upgrade", and when I clicked on the upgrade
> link it said "cannot connect".
>
> 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.
>
> And for each new host you visit, you have no cookie so the browser does
> that
> awful dance over and over. There are variants but you basically get the
> idea.
> Once you're on a site, you can browse it without problem as long as the
> cookie
> remains valid for the proxy.
>
> As you can see in this process, no explicit proxy features are used, what
> is
> important is that the request reaches the proxy. The difference will happen
> on https because explicit proxies will be able to forward CONNECT requests
> that match the white list without delivering a fake SSL cert, while an
> intercepting proxy cannot do that.
>
> Users experience a lot of issues with these methods. Some CSS sometimes
> appear broken, some images as well. Sometimes you can't see some videos,
> etc... It all depends at what step you're required to authenticate and
> when your browser will correctly follow the dual-redirect dance and let
> you enter your credentials.
>
> So the admin's goal here is just to get rid of end users complaints and
> trouble to upgrade deployed software by simply setting up an explicit
> proxy with native proxy auth, which all products support. But this is
> only acceptable if this proxy is used over an encrypted channel because
> of the credentials.
>

OK, please correct me if I'm wrong, but this is more detail about why we
need HTTPS proxies, right? If so, it sounds reasonable to me.


>
> (...)
> > Just to be clear, if all we're talking about is a configured HTTPS proxy,
> > as opposed to existing configured HTTP/SOCKS proxies, then I totally see
> > the incentive for it. The browser<=>proxy connection is not secured and
> > it'd be nice to secure it. I guess I was lumping in the "trusted" bit too
> > that I see in lots of proposals.
>
> In my opinion, explicit proxies only have a future with HTTPS now, and
> they will definitely be useful and will solve a number of issues users
> face today.
>
> Regards,
> willy
>
>