Re: Trusted Proxy Alternatives Analysis

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