Re: explicitly authenticated proxy: new draft

Some good background reading about the effectiveness of user security:
https://www.cs.berkeley.edu/~devdatta/papers/alice-in-warningland.pdf

Another interesting one:
http://www.andrew.cmu.edu/user/nicolasc/publications/CEVG-FC11.pdf

There are many non-browser clients which speak http, which it seems like
are not being heavily considered here. Many of them may not have UI
affordances to deal with user consent in cases like this. Even if there is
enough UI surface to provide a user prompt, the developers may not have
even considered this case since it only happens on certain networks - we've
certainly seen this happen with HTTP authenticating proxies in the past.
The networking libraries they use would probably want good default behavior
here - which would likely be the "opt-out" decision. This mechanism then
adds additional client complexity for limited change in behavior.



On Thu, Jun 19, 2014 at 1:42 AM, Mark Nottingham <mnot@mnot.net> wrote:

>
> On 18 Jun 2014, at 4:54 pm, Salvatore Loreto <
> salvatore.loreto@ericsson.com> wrote:
>
> >
> > On Jun 18, 2014, at 3:49 AM, Mark Nottingham <mnot@mnot.net> wrote:
> >
> >>> The main problem is really how dynamically configure and authenticate
> a proxy that is inline to the user
> >>> (i.e. specific to the access network)
> >>>
> >>> The draft proposes to use the Proxy Certificate as a way for the Proxy
> to authenticate itself and at same time trigger
> >>> the consent request into the Browser and show to the end user.
> >>
> >> It sounds a lot like you're talking about a "transparent" proxy --
> i.e., one that's not explicitly configured by the user (or their
> administrator on their behalf). Is that the case, or do I misunderstand?
> >
> > maybe its me or maybe a terminology problem here.
> >
> > does the fact that the configuration parameters are not explicitly
> inserted by hand (by the user or their administrator on their behalf) make
> the proxy a transparent one?
> > IMO a lots depends on how the automatic configuration happens.
> > The auth-draft is proposing a mechanism where the proxy manifests itself
> and asks the consent to the user (thru a popup window showing the right
> info to make
> > a conscious decision) and then only if the user provides consent that
> proxy is "automatically" configured by the proxy.
> >
> > So at the end the user is always made aware of the fact that there is a
> proxy (the one that has manifest itself) in between himself and the content.
> > this mechanism, as proposed, actually is per network access and limited
> in time.
>
> Right. That approach has been consistently rejected by most browser
> security people, because it's very similar to a cert error; the user will
> just click through it to get to the information they want.
>
> > I think this proposal make even more explicit compared to a proxy
> configured by the administrator on behalf of the user or even of one
> configured by the user and then forgotten.
>
> The difference, I think, is that when you insert a security decision in
> the middle of a user action, the user is much less likely to make an
> informed decision. While the proxy configuration is hidden away in most
> browsers, it's set up as a separate mechanism.
>
> Furthermore, experience with HTTP authentication shows that
> limited-content dialogues with no presentation control by the
> authenticating party often don't provide enough context to make an informed
> decision. I suspect that the same dynamic will evidence here; a cert
> extension has very limited ability to convey information...
>
> These are just my impressions based upon past conversations. Let's discuss
> this in Toronto and get some wider input.
>
> Cheers,
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>
>
>
>