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

Re: What will incentivize deployment of explicit proxies?

From: 陈智昌 <willchan@chromium.org>
Date: Mon, 9 Dec 2013 17:45:48 -0800
Message-ID: <CAA4WUYgxkQ9NqJTD2-Nuz5udzU8vHyOtyuNLhgOAe6qtd_QOmA@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Mark Nottingham <mnot@mnot.net>, Adrien de Croy <adrien@qbik.com>, Roberto Peon <grmocg@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Dec 9, 2013 at 4:26 PM, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:
>
>
> On 12/09/2013 11:59 PM, Mark Nottingham wrote:
>>
>> On 9 Dec 2013, at 7:40 pm, Stephen Farrell
>> <stephen.farrell@cs.tcd.ie> wrote:
>>
>>>
>>> Messing with root stores sounds like a TLS MITM rather than
>>> addressing proxies in HTTP since not all such stores are protocol
>>> specific. That would be a significant issue.
>>
>> People are already messing with root stores.
>
> Really? Using some IETF standard protocol? We actually have
> one of those (RFC 5934) that afaik has had zero deployment
> even though if I recall correctly, the folks behind that
> did try to interest browser makers. I think they were told
> that the browsers preferred to manage roots as part of their
> s/w update. Has that changed?

Mozilla controls its own SSL root certificates. Other browsers use the
OS configured SSL root certificates. See
http://techlib.barracuda.com/BWFSSLDefaultCert for an example of
documentation provided on how to configure this.

>
>> What I'm talking about
>> below is placing constraints on how they can do that, and making the
>> messing more visible to end users.
>
> And you're going to do that analysis of how that'd impact
> on all other consumers of TLS?

Just so we're clear, the common methods already in use impact all
consumers of TLS, not just browsers. They're getting added to the
system certificate store, so they affect all applications. But the
primary reason that it gets installed in the system certificate store
is because these proxies want to MITM browser connections.

>
> I'll also be interested in how end users will be protected
> from root-insertion attacks from pretty much anywhere if
> this becomes anywhere near common.
>
> S.
>
>>
>> Cheers,
>>
>>
>>>
>>> S
>>>
>>> Adrien de Croy <adrien@qbik.com> wrote:
>>>>
>>>> and DLP (data leakage protection)
>>>>
>>>>
>>>> ------ Original Message ------ From: "Roberto Peon"
>>>> <grmocg@gmail.com> To: "Mark Nottingham" <mnot@mnot.net> Cc:
>>>> "HTTP Working Group" <ietf-http-wg@w3.org> Sent: 9/12/2013
>>>> 5:17:26 p.m. Subject: Re: What will incentivize deployment of
>>>> explicit proxies?
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Dec 8, 2013 at 6:33 PM, Mark Nottingham <mnot@mnot.net>
>>>>> wrote:
>>>>>> This thread makes me wonder if, rather than focusing on
>>>>>> introducing a
>>>>
>>>>>> new kind of proxy to address the “enterprise/school/prison”
>>>>>> (ESP) use
>>>>
>>>>>> case, we* should instead focus on fixing how trust roots are
>>>>>>  configured and managed in browsers / OSs.
>>>>>>
>>>>>> I say that because the requirement is already being met in
>>>>>> the
>>>> market;
>>>>>> ESPs are able to inspect and modify traffic as it goes by on
>>>>>> the wire
>>>>
>>>>>> by configuring a new trust root. It’s just that there are
>>>>>> some nasty side effects brought about by that solution.
>>>>>>
>>>>>> We may be able to mitigate the bad effects of the current
>>>>>> solution — e.g., by allowing the user to understand when
>>>>>> their browser is using
>>>> a
>>>>>> trust root that was added later (AIUI some versions of Chrome
>>>>>> already
>>>>
>>>>>> do this visually?), by giving the user more fine-grained
>>>>>> control over
>>>>
>>>>>> what new certificates can be used for (to address the BYOD
>>>>>> user),
>>>> etc.
>>>>>>
>>>>>> If we can do that, we avoid the potential for new security
>>>>>> choices in
>>>>
>>>>>> front of non-enterprise end users, ones that Will is
>>>>>> justifiably nervous about (since anything that would allow a
>>>>>> MITM warning to be clicked through is a VERY attractive
>>>>>> attack vector).
>>>>>>
>>>>>> The one thing that wouldn’t be addressed by this approach is
>>>>>> the potential for a “semi-trusted” proxy that can see inside
>>>>>> encryption and yet promises e2e integrity. So, to me it seems
>>>>>> like we should be focusing on the use cases that lead us
>>>>>> there (rather than on that particular solution, yet).
>>>>>>
>>>>>> The one that’s been clearly identified is shared caching; is
>>>>>> there another?
>>>>>
>>>>> malware/virus scanning
>>>>>
>>>>> -=R
>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>>
>>>>>> * for some value of “we". Not every problem needs to be hit
>>>>>> with an HTTP-shaped hammer.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 7 Dec 2013, at 7:26 am, Werner Baumann
>>>>>> <werner.baumann@onlinehome.de> wrote:
>>>>>>
>>>>>>> Am Tue, 3 Dec 2013 10:53:26 -0800 schrieb William Chan (陈智
>>>>>>> 昌) <willchan@chromium.org>:
>>>>>>>
>>>>>>>>
>>>>>>>> <pushback> I can probably expect to be tarred and
>>>>>>>> feathered by my security
>>>>>> team
>>>>>>>> if I tell them we need to put up a UI asking the end user
>>>>>>>> to make
>>>> a
>>>>>>>> decision about security :) </pushback>
>>>>>>>>
>>>>>>> Yes, that's the problem with your security team. Talking
>>>>>>> about
>>>>>> security
>>>>>>> for the end user, but the one party that has no saying is
>>>>>>> the end
>>>>>> user.
>>>>>>>
>>>>>>> Talking as an end user: It is me, and only me, who decides
>>>>>>> whom to trust in which respect and to what extend. It is
>>>>>>> not your security
>>>>
>>>>>> team.
>>>>>>>
>>>>>>> Sure, there are users who don't care. And there are lot of
>>>>>>> users
>>>> who
>>>>>>> can't make informed decisions, because all the necessary
>>>> information
>>>>>> is
>>>>>>> hidden from them, many times by UI-experts who work based
>>>>>>> on the
>>>>>> dogma
>>>>>>> that users are stupid.
>>>>>>>
>>>>>>> Werner
>>>>>>>
>>>>>>
>>>>>> -- Mark Nottingham   http://www.mnot.net/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>>
>>
>> -- Mark Nottingham   http://www.mnot.net/
>>
>>
>>
>>
>>
>>
>
Received on Tuesday, 10 December 2013 01:46:17 UTC

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