Re: comparing eproxy proposals

[Roberto Peon <[e-mail]>]

On Sat, Jan 18, 2014 at 8:54 AM, Peter Lepeska <[e-mail]> wrote:

> As an exercise, I’ve attempted to define the 5 eproxy schemes that
> have been proposed up until now. And then compared these schemes to
> the eproxy GOALS section described here:
> http://tools.ietf.org/html/draft-vidya-httpbis-explicit-proxy-ps-00.
>
> Here are the five proposed HTTP2S eproxy schemes:
>
> 1. MITM -- This is the current way TLS is proxied that involves the
> proxy generating certs to impersonate the content server.
>
> 2. Proxy Server TLS Extension -- Described here:
> http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-01. Using a
> proposed extension to TLS, the proxy forwards the server cert to the
> client so that it can authenticate the content server. I think of this
> as MITM without impersonation, but I hope that doesn’t misrepresent
> the proposal.
>
> 3. Shared decryption key material -- This idea is described in both
> http://tools.ietf.org/html/draft-rpeon-httpbis-exproxy-00 and
>
> http://tools.ietf.org/html/draft-loreto-httpbis-trusted-proxy20-00#section-4.1
> .
> The core concept, in my understanding, is that the proxy is able to
> see the end-to-end TLS traffic in plaintext b/c the UA exports the
> session key and uploads it to the proxy.
>
> 4. Client forwards plaintext requests to secure proxy -- This idea is
> also described in both the rpeon exproxy draft and the loreto trusted
> proxy draft (links above). The concept is that two standard
> point-to-point (P-t-P) TLS sessions are established between client and
> proxy and proxy and server and then the browser simply forwards its
> HTTP2 requests to the proxy over that secure link.
>
> 5. Any Node Refusal -- This is the proposal I posted to the mailing
> list earlier and have re-posted here --
>
> https://github.com/bizzbyster/AnyNodeRefusal/wiki/HTTP2S-Eproxy-with-Any-Node-Refusal
> -- that leverages James’ intra-connection TLS negotiation to establish
> an unencrypted end-to-end TLS session across two point-to-point
> encrypted sessions. As the name implies, any node can refuse, data
> integrity is guaranteed, and the proxy cannot operate in stealth mode.
>
> Now to see which goals are met by each proposal...
>
> 6.2.  Goals
>
>    These are the goals of a solution aimed at making proxying explicit
>
>    in HTTP.
>
>    o  In the presence of a proxy, users' communications SHOULD at least
>
>       use a channel that is point-to-point encrypted.
>
> All meet this.
>
>    o  Users MUST be able to opt-out of communicating sensitive
>
>       information over a channel which is not end-to-end private.
>
> All but MITM meet this.
>
>    o  Content-providers MAY serve certain content only in an end-to-end
>
>       confidential fashion.
>
> Only Any Node Refusal meets this.
>
>    o  Interception proxies MUST be precluded from intercepting secure
>
>       communications between the user and the content-provider.
>
> I don’t really understand this one. Isn’t this a question of how you
> establish trust? That is not defined in any of these schemes.
>

This is saying something very obvious, and thus potentially confusing :)
Essentially, if you+endpoint believe it should be confidential, then it
should be confidential.


>
>    o  User-agents and servers MUST know when a transforming proxy is
>
>       interposed in the communications channel.
>
> Only Any Node Refusal meets this.


>    o  User-agents MUST be able to detect when content requested with an
>
>       https scheme has been modified by any intermediate entity.
>
> Only Any Node Refusal meets this.
>
>    o  Entities other than the server or user-agent SHOULD still be able
>
>       to provide caching services.
>
> I think all meet this except #3 above, Shared Decryption Key Material.
> I can’t see how that scheme can provide caching services.


>    o  User agents MUST be able to verify that the content is in fact
>
>       served by the content provider.
>
> Only Any Node Refusal and Shared Decryption Key Material meet this.
>
>    o  A set of signaling semantics should exist which allows the
>
>       content-provider and the user to have the appropriate level of
>
>       security or privacy signaled per resource.
>
> Only Any Node Refusal meets this.
>
>    o  Ideally, HTTP URI semantics SHOULD NOT change, but if it does, it
>
>       must remain backwards-compatible.
>
> All meet this, I believe.
>
>    o  Configuration and deployment of proxies should be as easy as
>
>       currently used solutions.
>
> I think this really depends on how trust is established, which isn’t
> covered by these proposals.
>
>    o  Introduction of explicit proxying MUST NOT require a flag day
>
>       upgrade - in other words, it should work with existing client and
>
>       content provider implementations during the transition.
>
> I don’t think any require this.
>
> Conclusion: I think the eproxy spec has to address three difficult
> things: 1) discovery of proxies, 2) establishing trust, and 3) the
> runtime requirements of UAs, proxies, and servers as defined by the
> GOALS section above. All three are really hard problems but I think
> ANR is a step towards solving #3.
>
>
I'm fairly certain that all of these goals are met with the eproxy draft I
submitted way back when, except for proxy discovery, and trust
establishment, which I didn't go into since the mechanisms for that were
likely separate from the mechanisms of the proxying itself.
I'm happy to go into individual points if you like, but I don't really
think it matters, All solutions in the space end up being roughly the same
thing with different bikeshed colors :)
-=R


> Thanks,
>
> Peter
>
>