Re: multiplexing -- don't do it

On Mon, Apr 2, 2012 at 3:28 PM, Adrien W. de Croy <adrien@qbik.com> wrote:

>
> ------ Original Message ------
> From: "Roberto Peon" <grmocg@gmail.com>
> To: "Adrien W. de Croy" <adrien@qbik.com>
> Cc: "Mike Belshe" <mike@belshe.com>;"Amos Jeffries" <squid3@treenet.co.nz
> >;"ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
> Sent: 3/04/2012 10:02:56 a.m.
> Subject: Re: multiplexing -- don't do it
>
> I don't trust proxies... hopefully that is apparent, but I'm asking for
> explicit support for them and attempting to deny support for non explicit
> proxies.
>
> I don't have a problem with proxy usage moving to explicit only.  We've
> been trying to get customers to move in that direction for years.
>
> Customers do like using interception though.  Educating them costs money.
> Not providing the feature would cost us sales, until we could get
> commitment from every other vendor to deprecate the feature.
>
> if 2.0 can fix this by providing a path forward which doesn't allow it,
> then everyone will be in the same boat, which is fine with me.
>

If we got SSL interception to work with trusted proxies, it would be a huge
feature to a lot of corporate sites. Not having to roll out SSL MITM is
really valuable to them.

I'm 100% sure that Chrome & Firefox would get behind a solution which
enforced SSL more often and required browsers to support more features with
trusted SSL to proxies.

Mike




>
>
>  On a related point, I'd like to see content signed so that when it is
> munged, it is detectable. This helps to change the trust game because it
> allows a site to specify (without possibility of modification) policy to
> the UA about the fetching of further resources, even through an explicit
> proxy.
>
>
> I think there will still be cases where trusting a proxy will be
> required.  In the end, if you use it, it can do anything.  If your browser
> sends any request to it over SSL, then the opportunity for decisions based
> on trust are pretty much gone already.
>
> Adrien
>
>
> -=R
>
> On Mon, Apr 2, 2012 at 2:59 PM, Roberto Peon < <grmocg@gmail.com>
> grmocg@gmail.com> wrote:
>
>>
>>
>>  On Mon, Apr 2, 2012 at 2:48 PM, Adrien W. de Croy < <adrien@qbik.com>
>> adrien@qbik.com> wrote:
>>
>>>
>>> ------ Original Message ------
>>> From: "Roberto Peon" <grmocg@gmail.com>grmocg@gmail.com
>>>
>>>
>>>
>>>>
>>>> Maybe we need a better way to force a client to use a proxy, and take
>>>> the pain out of it for administration.  And do it securely (just
>>>> remembering why 305 was deprecated).
>>>>
>>>
>>> like normal proxy configuration?
>>>
>>>
>>> you ever worked on an ISP support desk?
>>>
>>
>> Umm, actually I have.
>>
>>
>>>
>>> These are people who can hardly use a mouse you're trying to get them to
>>> set up proxy config in their browser?
>>>
>>>
>>
>> I'm familiar with these kinds of people and working with them. I'd
>> imagine that the ISP would give them an installer which would find and set
>> config for these programs without the user having to do it themselves or
>> something similarly easy.
>>
>>
>>>
>>> Assuming proxies were not explicit, what do you propose the users do the
>>> ISP begins filtering and censoring content for reasons of greed?
>>> -=R
>>>
>>>
>>> More likely due to statutory requirements.  You guys may think you
>>> dodged a bullet with SOPA... other countries you wouldn't expect have
>>> already passed laws requiring censorship by ISPs
>>>
>>> It's not an issue that's going away either.
>>>
>>
>> You're assuming that the ISP's incentives align with the user? I don't. I
>> imagine there are some out there who do and are, but on the whole, if
>> the capability to make more money exists from installing a box that does
>> something to the user's traffic, I'd expect that it gets done.
>> Off the top of my head, they can inspect what is going on and sell the
>> data of people's behaviors. You could also degrade the service quality for
>> any site that was in competition with any that your company (or affiliate)
>> provided. Note well that these have already happened. This is NOT
>> theoretical.
>>
>> -=R
>>
>>
>>>
>>>
>>>
>>>
>>>
>>
>

Received on Monday, 2 April 2012 22:37:26 UTC