Re: Trusted proxy UI strawman

On Wed, Jun 18, 2014 at 4:48 AM, Nicolas Mailhot <
nicolas.mailhot@laposte.net> wrote:

>
> Le Lun 16 juin 2014 21:47, William Chan (陈智昌) a écrit :
> > On Jun 16, 2014 2:19 PM, <bizzbyster@gmail.com> wrote:
>
> >> I don't follow what you are saying about security issues around caching
> > sub resources for active content? How is it different from when trusted
> > proxy is not active?
> >
> > Let's say I visit https://foo.com which uses a jQuery URL (perhaps
> hosted
> > by a CDN like Google's). A MITM proxy can cause a non-canonical version
> of
> > jQuery to be cached.
>
> This seems a strawman for me – if you've gone to the length of checking
> external code is safe from a security POW it is *idiotic* not to host the
> checked version on your own site instead of relying on an external
> reference.
>
> OTOH if you're referencing something from a third party, you've already
> delegated your security and adding a proxy to the mix is not going to
> change a lot to the situation. And don't tell me the people who do this
> monitor the reference to check for changes and audit those changes.
>

The need to trust a third party is definitely a problem for content authors
today. This is one use case for the Subresource Integrity proposal:
http://www.w3.org/TR/2014/WD-SRI-20140318/#resource-integrity-1.

That said, I do not agree with your assertion that referencing content from
a third party is equivalent to being willing to trust a proxy. I am frankly
surprised to hear such a statement. Does anyone else agree with this?


> And you can argue you trust the third party more than the proxy, but
> that's *your* opinion not necessarily the opinion of your users so the
> transitive trust issue was opened up the moment js hosting was delegated
> to a third party. Current browser UI does not inform users that when they
> visit nicecite.com they're really executing monitoring.js from
> bigbrother.com.


> The nice thing about proxying is that is exposes all the trust issues
> caused by mashing up resources without thinking about the security
> aspects, instead of burying them in the browser cache where no one thinks
> to look before it's too late.
>
> --
> Nicolas Mailhot
>
>