Re: Trusted Proxy Alternatives Analysis

"* Increased SSL usage may apply pressure to optimize the
domain/"location" usage. So we may be hopeful that the situation here
might improve."

Not sure who this is good for though. Which of the above content owners
wants to offload their content ownership? I mean, the list above is
essentially CDNs, Google, Facebook, and Twitter. I doubt any of that gang
is excited to sacrifice their ownership (or share private keys) to allow
abcnews.com to deploy over TLS in a way that does not significantly degrade
page load performance.

Also, is it a good thing that we are creating an architecture where page
load time has to be traded off against diversity of page content? To me,
the mashup (the ability to coherently display content from many sources on
one page) is one of the things that makes the web so successful and not
something I'd want to discourage via a performance penalty.

In general, the need for reverse proxies to mitigate the performance
penalty of HTTP2 over TLS feels like a contortion. Forward proxies are
ideally positioned to see all content and provide last mile optimization
(caching, accleration, etc.) optimized for the unique characteristics of
the access network. Ironically, I think forward proxies are needed to move
TLS coverage on the web beyond single domain sites like Google, Facebook,
Twitter, and ecommerce/banking sites b/c they are best able to minimize the
performance impact of making that switch.

Peter


On Fri, Feb 7, 2014 at 4:42 PM, William Chan (陈智昌) <willchan@chromium.org>wrote:

> By and large I agree with many of your points. Let me offer a few
> points to consider though:
> * Increased SSL usage may apply pressure to optimize the
> domain/"location" usage. So we may be hopeful that the situation here
> might improve.
> * While there are a lot of different domains used, the ones critical
> to page load are primarily hosted on a.abcnews.com. First render
> happens well before many of the 3rd party resource loads are even
> initiated.
> * We might be able to come up with ways to provide additional
> protection for content (thus mitigating your private key concern). For
> example, Subresource Integrity is one such proposal:
> http://w3c.github.io/webappsec/specs/subresourceintegrity/.
>
> On Fri, Feb 7, 2014 at 10:46 AM, Peter Lepeska <bizzbyster@gmail.com>
> wrote:
> > I also want to point out that a reverse proxy can provide trusted forward
> > proxy functionality only if the same reverse proxy sees all the content.
> For
> > many large mashup sites this is likely to be a difficult thing to achieve
> > logistically:
> >
> > If we look at www.abcnews.com for example
> > (http://www.webpagetest.org/result/140207_MQ_WDN/1/details/), we see
> that
> > content is spread across 40 FQDNs, 22 unique domains and 9 unique
> > "Locations" including three different CDNs (Akamai, Edgecast, and
> Fastly).
> >
> > URL Location
> > ---------------------------------- -------------
> > http://www.abcnews.com/ Burbank, CA
> > http://abcnews.go.com/ Burbank, CA
> > http://cdn.optimizely.com/ Edgecast
> > http://2912a.v.fwmrm.net/ Atlanta, GA
> > http://connect.facebook.net/ Akamai
> > http://platform.twitter.com/ Edgecast
> > http://p.typekit.net/ Edgecast
> > http://nmp.newsgator.com/ Redmond, WA
> > http://js.adsonar.com/ Akamai
> > http://embed.scribblive.com/ Akamai
> > http://edge.quantserve.com/ Ashburn, VA
> > http://www.googleadservices.com/ Atlanta, GA
> > http://secure-us.imrworldwide.com/ Schaumburg, IL
> > http://cdn.tacoda.at.atwola.com/ Akamai
> > http://www.google-analytics.com/ Google
> > http://www.google.com/ Google
> > http://p.twitter.com/ Akamai
> > http://pbs.twimg.com/ Edgecast
> > http://b.scorecardresearch.com/ Akamai
> > http://static.ak.fbcdn.com/ Akamai
> > http://static.chartbeat.com/ Fastly
> >
> > Do we really think it's realistic that all of this content could be
> served
> > by a single, or a small number of reverse proxy / CDNs? Do we even want a
> > single or a small number of CDN operators to have the private keys for
> all
> > content on the Internet? That level of centralization might be seen as a
> > step backwards in security terms.
> >
> > Hope this isn't too much of a digression -- my main point is just that
> CDNs
> > are an inadequate replacement technology for forward proxies in many
> cases.
> >
> > Thanks,
> >
> > Peter
> >
> >
> > On Fri, Feb 7, 2014 at 10:00 AM, Peter Lepeska <bizzbyster@gmail.com>
> wrote:
> >>
> >> Hi Frode,
> >>
> >> I would like to faithfully update the table to reflect the groups
> thoughts
> >> on this but I have to say I'm confused by what you are proposing. When
> you
> >> say this "Regarding the "identity binding", an alternative is of course
> to
> >> do this end-2-end." aren't you essentially saying that this could be
> solved
> >> by reverse proxy / CDN? Which is what I've already put in the
> Alternatives
> >> column for the Mike's Music Service use case.
> >>
> >> Maybe I need to clarify some assumptions about forward versus reverse
> >> proxy. In general, unlike a forward proxy, a reverse proxy is deployed
> by
> >> the content owner or the content owner partner ("CDN") and so has the
> >> private keys and so does not need to ask the user for "trust" in order
> to
> >> decrypt the data.
> >>
> >> Does that clarify anything?
> >>
> >> thanks,
> >>
> >> Peter
> >>
> >>
> >> On Fri, Feb 7, 2014 at 6:54 AM, Frode Kileng <frodek@tele.no> wrote:
> >>>
> >>> Hi Emilie
> >>>
> >>>
> >>> On 07.02.2014 12:23, emile.stephan@orange.com wrote:
> >>> > Hi Frode,
> >>> >
> >>> >  The term MITM in not appropriate for these cases: the service
> >>> > augmentation
> >>> >  is performed by the reverse proxy of the mobile operator. This
> reverse
> >>> > proxy
> >>> >  receives and processes the requests for the service provided by the
> >>> > mobile
> >>> >  operator.
> >>>
> >>> Is the client configured to use this proxy? If not, I prefer to use
> MITM
> >>> although the wording may not be the the most important isue...
> >>>
> >>> Regarding the "identity binding", an alternative is of course to do
> this
> >>> end-2-end. If this for some reason isn't an alternative, I would
> propose
> >>> that the use case description clearly states why, both in regard to
> end-user
> >>> experience ("User benefit") and/or service/network provider issues
> ("Admin
> >>> Benefit").
> >>>
> >>> Regards
> >>> Frode Kileng
> >>>
> >>>
> >>
> >
>