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
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
>>>
>>>
>>
>
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