Re: The future of forward proxy servers in an http/2 over TLS world

Kari Hurtta <hurtta-ietf@elmme-mailer.org> Fri, 17 February 2017 04:55 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A66C1293E1 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 16 Feb 2017 20:55:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Gpv9Gm1mil6m for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 16 Feb 2017 20:55:29 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1055E127058 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 16 Feb 2017 20:55:29 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ceaXy-0006zW-NS for ietf-http-wg-dist@listhub.w3.org; Fri, 17 Feb 2017 04:53:30 +0000
Resent-Date: Fri, 17 Feb 2017 04:53:30 +0000
Resent-Message-Id: <E1ceaXy-0006zW-NS@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <khurtta@welho.com>) id 1ceaXt-0006xw-D7 for ietf-http-wg@listhub.w3.org; Fri, 17 Feb 2017 04:53:25 +0000
Received: from welho-filter2.welho.com ([83.102.41.24]) by mimas.w3.org with esmtp (Exim 4.84_2) (envelope-from <khurtta@welho.com>) id 1ceaXi-0007v6-7O for ietf-http-wg@w3.org; Fri, 17 Feb 2017 04:53:16 +0000
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 798E51B04D; Fri, 17 Feb 2017 06:52:46 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id PSza762tUyRp; Fri, 17 Feb 2017 06:52:45 +0200 (EET)
Received: from hurtta09lk.keh.iki.fi (89-27-35-245.bb.dnainternet.fi [89.27.35.245]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPS id A0CA2C4; Fri, 17 Feb 2017 06:52:45 +0200 (EET)
In-Reply-To: <em2b16b855-c719-422a-9488-6c34893e2432@bodybag>
References: <em2b16b855-c719-422a-9488-6c34893e2432@bodybag>
To: HTTP working group mailing list <ietf-http-wg@w3.org>
Date: Fri, 17 Feb 2017 06:52:45 +0200
Sender: hurtta@hurtta09lk.keh.iki.fi
From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
CC: Adrien de Croy <adrien@qbik.com>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Ryan Hamilton <rch@google.com>, HTTP working group mailing list <ietf-http-wg@w3.org>
X-Mailer: ELM [version ME+ 2.5 PLalpha44+]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20170217045246.798E51B04D@welho-filter2.welho.com>
Received-SPF: none client-ip=83.102.41.24; envelope-from=khurtta@welho.com; helo=welho-filter2.welho.com
X-W3C-Hub-Spam-Status: No, score=-4.0
X-W3C-Hub-Spam-Report: AWL=-0.072, BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1ceaXi-0007v6-7O ae56201dd1360d53efc275264ab08e3d
X-Original-To: ietf-http-wg@w3.org
Subject: Re: The future of forward proxy servers in an http/2 over TLS world
Archived-At: <http://www.w3.org/mid/20170217045246.798E51B04D@welho-filter2.welho.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33565
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>

> But if the proxy can mint certs that are trusted by the browser, the 
> question is how is that.  The proxy would need to be using a signing 
> cert that is trusted by the browser, and how did it get installed in the 
> browser?

If proxy CA certificate can be installed to browser, then it is also possible
to install browser plugin to browser.

That browser plugin can implement some kind sidechannel. 

But different browsers and OSes, cpus need all diffrent plugin.
Proxy CA certificate format does not change here.

I see why that direction is selected.

And network border (or proxy) need some way to verify plugin
is active and sidechannel is in use on many use scenario.
Otherwise may be even disabled accidentally on browser update.

Hmm. One radical sidechannel is what tells symmectric encryption
key of TLS connection. I guess that this is not acceible for browser
plugin either. In that case proxy can verify that it have symmectric 
encryption key for TLS connection.


Internet Content Adaptation Protocol (ICAP, RFC 3507)
can perhaps act as standardised sidechannel protocol,
but that does not look like practical and is is
not implemneted by browsers. Basically that means
that content is moved several times. And also
network border (or proxy) can not verify that sidechannel
is on use.

/ Kari Hurtta