W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: What will incentivize deployment of explicit proxies?

From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
Date: Wed, 4 Dec 2013 10:04:50 +0100
Message-ID: <0fe0e25961fa44020a927df5312c4557.squirrel@arekh.dyndns.org>
To: "Ted Hardie" <ted.ietf@gmail.com>
Cc: "William Chan (陈智昌)" <willchan@chromium.org>, "Martin Thomson" <martin.thomson@gmail.com>, "Yoav Nir" <synp71@live.com>, "James M Snell" <jasnell@gmail.com>, "Tim Bray" <tbray@textuality.com>, "Roberto Peon" <grmocg@gmail.com>, "Nicolas Mailhot" <nicolas.mailhot@laposte.net>, "HTTP Working Group" <ietf-http-wg@w3.org>

Le Mer 4 décembre 2013 01:34, Ted Hardie a écrit :
> On Tue, Dec 3, 2013 at 4:22 PM, William Chan (陈智昌)
> <willchan@chromium.org>wrote:
>
>> OK, it sounds like people are retreating back from the
>> autoconfiguration+interstitial part of an explicit proxy
>> proposal...except
>> maybe Nicholas? I'd love to hear more thoughts on
>> autoconfiguration+interstitial. It sounds like the prevailing sentiment
>> is
>> it's unacceptable from a security UX perspective.
>>
>> And now we're back to one-time setup operations. And in contrast to MITM
>> proxies, we see an opportunity to improve on the UX here, since
>> installing
>> a root cert sucks. It seems like all browsers here rely on the system
>> for
>> proxy configuration (Pat corrected me earlier on that), so this will tie
>> us
>> to OS versions if we pursue this path. So if the OS vendors do not
>> improve
>> the UX for installing MITM proxies, and instead focus energies on
>> creating
>> a better explicit proxy configuration UX, then maybe that'll encourage
>> proxy operators to deploy more explicit proxies.
>>
>> That's probably most of the proxy incentives there.
>>
>
> I'm not sure that this is the case.  One nice thing about explicit proxies
> is that they do not need to be on-path, where interception proxies do.
> You
> could imagine someone creating a business that puts the explicit proxies
> into a data center and selling that as a service.  One of the issues with
> interception proxies is that you must cause the traffic to traverse the
> network segments where the interception takes place.  Being able to avoid
> that would be a big incentive, if the web ecosystem supported it.

Explicit proxies the user chose for its own reasons (tor...) do not need
to be on-path or even block direct proxy-less connexion. (though a
security aware user will block all other paths anyway to force the
eventual malware that gets installed on his devices to pass through his
proxy even if it does not want to)

Explicit proxies where the user is under some form of constraint (employer
demand, school rules…) only require ability to block direct connexions.
Though this could be trivially enhanced without wounding anyone if there
was a simple-enough see-gateway here even dumb firewalls could implement
without scaling problems.

-- 
Nicolas Mailhot
Received on Wednesday, 4 December 2013 09:05:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:20 UTC