comparing eproxy proposals
Peter Lepeska <bizzbyster@gmail.com> Sat, 18 January 2014 16:57 UTC
Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9891ADF73 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 18 Jan 2014 08:57:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.54
X-Spam-Level:
X-Spam-Status: No, score=-7.54 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpK6aNKaTDTj for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 18 Jan 2014 08:57:56 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id C45631ADF71 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 18 Jan 2014 08:57:55 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1W4ZAU-0002Ne-LI for ietf-http-wg-dist@listhub.w3.org; Sat, 18 Jan 2014 16:54:46 +0000
Resent-Date: Sat, 18 Jan 2014 16:54:46 +0000
Resent-Message-Id: <E1W4ZAU-0002Ne-LI@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <bizzbyster@gmail.com>) id 1W4ZAM-0002Mt-9i for ietf-http-wg@listhub.w3.org; Sat, 18 Jan 2014 16:54:38 +0000
Received: from mail-vc0-f177.google.com ([209.85.220.177]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <bizzbyster@gmail.com>) id 1W4ZAK-0002Yj-EU for ietf-http-wg@w3.org; Sat, 18 Jan 2014 16:54:37 +0000
Received: by mail-vc0-f177.google.com with SMTP id if11so2068701vcb.36 for <ietf-http-wg@w3.org>; Sat, 18 Jan 2014 08:54:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=QhogzSFtVgU3O+uoIHmHu/3WoqCyINqSN8h1QkRDjeU=; b=WGEL6xeFLa+T+HLoz8crIZo3Ykd2Ee0j/aabmafZueloyqvOJ9kZowcbwQ2tqmAqjj EWd4VWefwCAUH1NzwrPobE1x7jFRu9JM6P4MogLh9EX7u5uJIOntqB7y0Ss6Z0jI99fC ZcGB0np3z2lSK8+5xOcJqNtrzVg9wAK+ek8KCkiD7C46j+2xUFQI/EdXkJMiyWDo5UBm 4brp4FUSRvMlgR5IFYM7/ogu1c3et6W7TbeWz3zSMNyYYK7Bd9RvPw7hUS483l5WtxhM YFYV+HWywsugElw/6FIVgz+MO37HVKMurpfsMYz+gKbiy/qasb8PpTq3uFisQHiqAO5P vE8Q==
MIME-Version: 1.0
X-Received: by 10.58.90.1 with SMTP id bs1mr47074veb.29.1390064050251; Sat, 18 Jan 2014 08:54:10 -0800 (PST)
Received: by 10.58.155.232 with HTTP; Sat, 18 Jan 2014 08:54:10 -0800 (PST)
Date: Sat, 18 Jan 2014 17:54:10 +0100
Message-ID: <CANmPAYFm=Vm-L=smSU8XVN6N4fjWWYr=Y0u+Bkg4ryWopZvUbA@mail.gmail.com>
From: Peter Lepeska <bizzbyster@gmail.com>
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=209.85.220.177; envelope-from=bizzbyster@gmail.com; helo=mail-vc0-f177.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.700, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1W4ZAK-0002Yj-EU 00a27f831d4037622ecaac85c3865c18
X-Original-To: ietf-http-wg@w3.org
Subject: comparing eproxy proposals
Archived-At: <http://www.w3.org/mid/CANmPAYFm=Vm-L=smSU8XVN6N4fjWWYr=Y0u+Bkg4ryWopZvUbA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/21893
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
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. 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
- comparing eproxy proposals Peter Lepeska
- Re: comparing eproxy proposals Poul-Henning Kamp
- Re: comparing eproxy proposals Stephen Farrell
- Re: comparing eproxy proposals Peter Lepeska
- Re: comparing eproxy proposals Roberto Peon
- Re: comparing eproxy proposals Peter Lepeska