- From: Roberto Peon <grmocg@gmail.com>
- Date: Sat, 18 Jan 2014 14:28:26 -0800
- To: Peter Lepeska <bizzbyster@gmail.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <CAP+FsNcj_pVgcvw53K0-9yD3s6t25MY_HtbKxwA1n4xeg-Vdfg@mail.gmail.com>
On Sat, Jan 18, 2014 at 8:54 AM, Peter Lepeska <bizzbyster@gmail.com> 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 > >
Received on Saturday, 18 January 2014 22:28:54 UTC