W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

Re: Trusted Proxy Alternatives Analysis

From: (wrong string) 陈智昌 <willchan@chromium.org>
Date: Fri, 7 Feb 2014 13:42:13 -0800
Message-ID: <CAA4WUYgvpbD64t5GLFdwTaxhmjqvPiCvMSNFa2v8+RugvmD=+A@mail.gmail.com>
To: Peter Lepeska <bizzbyster@gmail.com>
Cc: Frode Kileng <frodek@tele.no>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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
* 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:

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
Received on Friday, 7 February 2014 21:42:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC