Re: comparing eproxy proposals -- with some corrections

[Peter Lepeska <[e-mail]>]

I realized that #4 (my understanding of Salvatore's proposal) can be
enhanced by having the proxy send the content server cert down to the
browser ahead of any application data so that the browser can do its own
certificate validation. This essentially adds the benefits of #2 to #4
below.

I've also been thinking about the fact that implementors do not typically
have the ability to make mods to client, proxy, AND web server (with the
exception of nghttp that I'm aware of). Therefore the choice of which
eproxy proposal to implement should one desire to take the next step with
this is constrained by which of the three he or she has control over.

-- So, for instance, if you only control the proxy (squid for instance),
then MITM is the only choice you have. This is the do nothing case as we
don't currently have a proposal on the table for eproxy that requires
changes only to the proxy.

-- If you control proxy and browser, then 2, 3, and 4 are possible. Since
as I mention above #4 can be enhanced by forwarding the content server
certificate to the browser and it therefore eliminates transitive trust in
a way that is similar to #2, and it is the fewest round trips proposal
(assuming the HTTP2S point-to-point session to the proxy is already
established), I think #4 is the leading contender. Again, this is if you
only control browser and proxy.

-- If you have the ability to modify browser, proxy, and server, then a
scheme similar to the Any Node Refusal proposal makes the most sense to me,
given the goals in the vidya draft.

Thanks and I hope this helps to frame discussion and provide a useful
overview of what is being considered.

See some of you tomorrow.

Thanks,

Peter


On Sun, Jan 19, 2014 at 3:52 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 as I understand them:
>
> 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
> described in the loreto trusted proxy draft (link above see section
> 4.2). 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. In Roberto’s draft, a version of this idea also
> shows up relating to an end-to-end CONNECT using a null cipher over
> two p-t-p encrypted TLS 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.
>
>    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.
>
> Thanks,
>
> Peter
>