comparing eproxy proposals -- with some corrections

[Peter Lepeska <[e-mail]>]

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