Subject: comparing eproxy proposals -- with some corrections

From: Peter Lepeska <[email-masked]>
Date: Sun, 19 Jan 2014 03:52:19 +0100

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

---

From: Peter Lepeska <[email-masked]>
Date: Tue, 21 Jan 2014 17:46:42 +0100

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