Re: What will incentivize deployment of explicit proxies?

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.

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

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

(...)
> 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

Received on Tuesday, 3 December 2013 11:19:22 UTC