Subject: Trusted Proxy Alternatives Analysis

From: Peter Lepeska <[email-masked]>
Date: Thu, 6 Feb 2014 12:19:05 -0500

In Zurich there was a request to look into the viability of alternative
technologies for the trusted proxy use cases. To help organize thoughts
around this, I've created a table listing each use case from
https://github.com/http2/http2-spec/wiki/Proxy-User-Stories and an attempt
to describe how each of these cases can be addressed using today's
technology as well as alternatives:
https://github.com/bizzbyster/TrustedProxy/wiki/Trusted-Proxy-Use-Case-Analysis-and-Alternatives

This is just a straw man attempt to provide some organization so feel free
to question, comment and suggest improvements.

In summary, I think all use cases where the user owns the device are
inadequately solved by today's technology. As for alternatives, CDNs
partially address a subset of the use cases potentially, and then only on a
site by site basis.

Thanks,

Peter

---

From: Frode Kileng <[email-masked]>
Date: Thu, 06 Feb 2014 23:05:01 +0100

Great initiative Peter.

Regarding "Mike's Music Service". My understanding of this is use-case
is that it includes two parts:

1. Zero-rating of the mobile data traffic:
As long as the encrypted  traffic is not passing through a 3rd party 
proxy, the mobile operator can achieve this using traffic-meta data.

2. Identity binding
Similar to the functionality in "Liam's Mobile Identity Proxy". I.e. 
where the MITM proxy inserts an identity binding in the header for 
authentication towards a 3rd party service.

Regards
frodek

On 06.02.2014 18:19, Peter Lepeska wrote:
> In Zurich there was a request to look into the viability of 
> alternative technologies for the trusted proxy use cases. To help 
> organize thoughts around this, I've created a table listing each use 
> case from https://github.com/http2/http2-spec/wiki/Proxy-User-Stories 
> and an attempt to describe how each of these cases can be addressed 
> using today's technology as well as alternatives:
> This is just a straw man attempt to provide some organization so feel 
> free to question, comment and suggest improvements.
>
> partially address a subset of the use cases potentially, and then only 
> on a site by site basis.
>
> Thanks,
>
> Peter

---

From: <[email-masked]>
Date: Fri, 7 Feb 2014 11:23:01 +0000

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.  

Regards
Emile

-----Message d'origine-----
De : Frode Kileng [mailto:[email-masked]] 
Envoyé : jeudi 6 février 2014 23:05
À : [email-masked]
Objet : Re: Trusted Proxy Alternatives Analysis

Great initiative Peter.

Regarding "Mike's Music Service". My understanding of this is use-case is that it includes two parts:

1. Zero-rating of the mobile data traffic:
As long as the encrypted  traffic is not passing through a 3rd party proxy, the mobile operator can achieve this using traffic-meta data.

2. Identity binding
Similar to the functionality in "Liam's Mobile Identity Proxy". I.e. 
where the MITM proxy inserts an identity binding in the header for authentication towards a 3rd party service.

Regards
frodek

> partially address a subset of the use cases potentially, and then only 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Frode Kileng <[email-masked]>
Date: Fri, 07 Feb 2014 12:54:33 +0100

Hi Emilie

On 07.02.2014 12:23, [email-masked] 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

---

From: Peter Lepeska <[email-masked]>
Date: Fri, 7 Feb 2014 10:00:01 -0500

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 <[email-masked]> wrote:

> >  is performed by the reverse proxy of the mobile operator. This reverse
> proxy
> end-user experience ("User benefit") and/or service/network provider issues
> ("Admin Benefit").
>
> Regards
> Frode Kileng
>
>
>

---

From: Peter Lepeska <[email-masked]>
Date: Fri, 7 Feb 2014 13:46:58 -0500

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 <[email-masked]> wrote:

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

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 7 Feb 2014 13:42:13 -0800

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 <[email-masked]> wrote:
> 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
>>> 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
>>>
>>>
>>
>

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 9 Feb 2014 13:46:33 +0000

Hi Frode,

On Feb 7, 2014, at 1:54 PM, Frode Kileng <[email-masked]> wrote:

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

if the Music web site has partnered with a mobile operator,
most likely that means that the Music web site has "provided" his own certificate to the mobile operate
so the TLS session is terminated in the mobile operator reverse proxy and the user does not need any configuration.

of course if the partnership does not "include" the certificate delegation then it is another story 

br
Salvatore

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

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 9 Feb 2014 14:05:16 +0000

On Feb 7, 2014, at 8:46 PM, Peter Lepeska <[email-masked]<mailto:[email-masked]>> wrote:

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?

I don't think it is realistic, especially for the really small content providers (if it is correct to define them so) as the bloggers
or the people that at moment they have their own personal web site …
as we are implying that not only they should switch to support TLS (that can be a good thing for them, and for the Internet in general)
but we would also force them to partner with a CND operators

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.

I tend to agree that CDN is not a panacea,
CDN can be improve the situation in some case, but we have to be realistic here
and admit that it can be used as forward proxies replacement only in a really small part of
all the use cases where the forwarded proxy are used nowadays

/Salvatore

---

From: Frode Kileng <[email-masked]>
Date: Sun, 09 Feb 2014 21:39:06 +0100

Hi Salvatore,

> so the TLS session is terminated in the mobile operator reverse proxy and the user does not need any configuration.

This would of course also work.

> of course if the partnership does not "include" the certificate delegation then it is another story

Then end-to-end authentication is an option.

Best regards
Frode Kileng

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Mon, 10 Feb 2014 11:30:27 +0100

> http://w3c.github.io/webappsec/specs/subresourceintegrity/.

As is typical of such proposals, it does not consider that intermediaries
would also like to avoid cache poisoning.

Regards,

-- 
Nicolas Mailhot

---

From: Peter Lepeska <[email-masked]>
Date: Mon, 10 Feb 2014 07:41:52 -0500

"* 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 (陈智昌) <[email-masked]>wrote:

> For
> to
> reverse
> end-user

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 11 Feb 2014 13:39:52 +1100

Nicolas, 

Can you expand upon that? A throwaway dismissal like that doesn't really help.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Tue, 11 Feb 2014 20:05:40 +0100

> Can you expand upon that? A throwaway dismissal like that doesn't really

The integrity hash is buried in the html page (content). Therefore, when a
web client will perform a GET on one of those resources, proxies will only
see the URL and have no way to know it should be checked against
something.

For the security to be effective the integrity metadata needs to be
propagated in the web client http commands.

Regards,

-- 
Nicolas Mailhot

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 12 Feb 2014 15:52:46 +1100

> see the URL and have no way to know it should be checked against

In the most common case, the HTML page will be transferred over TLS, so the proxy won't have an opportunity to see it anyway (unless it is doing particularly nasty things).

> propagated in the web client http commands.

I think the security properties of that scheme are becoming well understood, and they are effective within certain bounds. They may not allow a proxy to "add value", but that isn't a necessary condition for every new addition to the Web, surely?

Cheers,

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 12 Feb 2014 10:33:21 +0100

Le Mer 12 février 2014 05:52, Mark Nottingham a écrit :

> I think the security properties of that scheme are becoming well
> understood, and they are effective within certain bounds. They may not
> allow a proxy to "add value", but that isn't a necessary condition for
> every new addition to the Web, surely?

It's not a case of adding value. It's a case of getting the ecosystem work
well. If you add a measure to fight cache poisoning, but forget to take
proxy caches into account, you have users, browser authors and site
authors complain that "the proxy broke the web site" when its cache gets
poisoned because the other actors forgot to inform it of the security hash
(and do not forget that some proxies are deployed explicitly to perform
such security checks!)

After months of lurking on this list I'm firmly convinced that 90% of the
angst against proxies is due to forgetting the last mile when writing http
specs, and that no proxy writer can provide a better user experience if
the other actors continue to dismiss proxy concerns at every opportunity.

Regards,

-- 
Nicolas Mailhot

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 13 Feb 2014 10:18:51 +1100

> (and do not forget that some proxies are deployed explicitly to perform

If you're concerned about that use case, I'd suggest you join that list and propose a mechanism (e.g., a request header that the client can use to convey the hash it expects -- but there are DoS implications, etc. there too). They're quite open to suggestions in my experience.

<http://www.w3.org/2011/webappsec/>

Cheers,