Re: What will incentivize deployment of explicit proxies?

On Tue, Dec 3, 2013 at 4:34 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

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

Indeed you are correct here.


>
>
> Ted
>
>
>
>> Now it's interesting to analyze the site operator incentives and the
>> browser incentives. Site operators will like explicit proxies, since they
>> probably like having more knowledge/power. Although there's the concern
>> Stephen raised earlier about banking site operators blocking access if an
>> explicit "trusted" proxy is present. This may impact the incentives of
>> proxy operators to deploy explicit proxies since they may not want site
>> operators to be able to do this. Thoughts on that?
>>
>> And now there are the UAs, of which browsers are the most prominent. For
>> tools like curl, I don't think they'd have a problem with "trusted"
>> proxies, since the user presumably knows what he's doing? Maybe? For
>> browsers though, I expect there will be some hesitance to sacrifice e2e
>> security guarantees. Pat already mentioned this earlier about his dislike
>> of proxy termination of https:// requests. My teammates have similarly
>> voiced concerns here. Would we be willing to move forward with explicit
>> HTTPS proxies (UA<=>proxy TLS connection) without any "trusted" modes? Or
>> is that a key part of the proposals?
>>
>> Cheers.
>>
>>
>> On Tue, Dec 3, 2013 at 3:07 PM, Martin Thomson <martin.thomson@gmail.com>wrote:
>>
>>> On 3 December 2013 14:37, Yoav Nir <synp71@live.com> wrote:
>>> > It might be prudent to sacrifice expediency and block all access
>>> through
>>> > unrecognized proxies. Adding an explicit proxy would then have to be
>>> done
>>> > through a different UI, not a prompt that surprises a user who is
>>> trying to
>>> > do something.
>>>
>>> That's exactly what we've decided to do for screen sharing in WebRTC.
>>> It's got a similar sort of security profile: deceptively simple, but
>>> in practice there are subtleties users cannot be expected to evaluate.
>>>  In that context, Chrome - the only browser thus far to even have
>>> screen sharing support - have decided to move access to this into
>>> their extension framework.
>>>
>>> In order to enable screen sharing in Chrome, sites will need to use an
>>> extension that enables screen sharing for their site.  That hasn't
>>> been a universally popular decision, but I believe it to be a
>>> reasonable one given the nature of the problem.  It takes the decision
>>> off the critical path; it allows for revocation of rights when there
>>> are bad actors; etc...
>>>
>>> I'm not suggesting that this is the right decision here, but some
>>> greater awareness of the sorts of things people are doing when
>>> presented with similarly tough decisions can't hurt.
>>>
>>
>>
>