The future of forward proxy servers in an http/2 over TLS world
"Adrien de Croy" <adrien@qbik.com> Tue, 14 February 2017 22:41 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 7D5D512940D for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 14 Feb 2017 14:41:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 9_SF1O3KeeoT for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 14 Feb 2017 14:41:07 -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 558D8129439 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 14 Feb 2017 14:41:07 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cdljR-00042D-FN for ietf-http-wg-dist@listhub.w3.org; Tue, 14 Feb 2017 22:37:57 +0000
Resent-Date: Tue, 14 Feb 2017 22:37:57 +0000
Resent-Message-Id: <E1cdljR-00042D-FN@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 <adrien@qbik.com>) id 1cdljL-0003zS-JQ for ietf-http-wg@listhub.w3.org; Tue, 14 Feb 2017 22:37:51 +0000
Received: from smtp.qbik.com ([122.56.26.1]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_ARCFOUR_128_SHA1:128) (Exim 4.84_2) (envelope-from <adrien@qbik.com>) id 1cdljD-0007jj-JY for ietf-http-wg@w3.org; Tue, 14 Feb 2017 22:37:46 +0000
Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v9.0.4 (Build 5915)) with SMTP id <0000964523@smtp.qbik.com>; Wed, 15 Feb 2017 11:37:12 +1300
From: Adrien de Croy <adrien@qbik.com>
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Date: Tue, 14 Feb 2017 22:37:12 +0000
Message-Id: <emde1bfa93-84c0-49f7-83a4-b9bed24e0276@bodybag>
Reply-To: Adrien de Croy <adrien@qbik.com>
User-Agent: eM_Client/7.0.27943.0
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="------=_MB58E80EB7-39C7-4387-B161-61F5BBD6FBD4"
Received-SPF: pass client-ip=122.56.26.1; envelope-from=adrien@qbik.com; helo=smtp.qbik.com
X-W3C-Hub-Spam-Status: No, score=-4.7
X-W3C-Hub-Spam-Report: AWL=-0.758, BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1cdljD-0007jj-JY fcba862d8d4822f6be1941eea2e1b728
X-Original-To: ietf-http-wg@w3.org
Subject: The future of forward proxy servers in an http/2 over TLS world
Archived-At: <http://www.w3.org/mid/emde1bfa93-84c0-49f7-83a4-b9bed24e0276@bodybag>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33502
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>
At the moment, it feels like the functions provided by proxy servers are being squeezed out by changes in the protocol. I can understand the desire for privacy, and we've had the argument about whether it should be available to all or not too many times already. However, there are other functions that a proxy is commonly used for that are becoming impossible with the direction TLS, HTTPS HSTS, cert pinning etc are going. Whilst I can understand a desire and need for privacy, an ability to be able to go to a website without betraying which site you're going to (e.g. see https://tools.ietf.org/html/draft-schwartz-dns-sni-01 <https://tools.ietf.org/html/draft-schwartz-dns-sni-01>) there's probably 1 remaining IMO critical bona fide purpose for a proxy which is becoming very problematic for users. Blocking requests. So, do we feel there is still a place for blocking requests? Our customers still certainly want this. Currently the user experience is either appalling (generic connectivity failure report which wastes a lot of user time), or requires deployment of a MitM, which is being squeezed out as well. We should be able to do better, but it doesn't appear to be being addressed at all, and the gulf is widening. I believe we need to put some time into working out how we can allow a proxy to block requests without an awful user experience that costs users and tech support countless hours to deal with. This means we have a need to be able to respond to CONNECT with a denial, and some kind of message that can be displayed to the user. It may be that the only way this can be achieved is by the concept of a trusted proxy. Otherwise if the group consensus is that requests should not be blocked, we need to deal with the consequences of that. Adrien P.s. another key feature is caching, but that is becoming less useful anyway. Customers can often live without caching, they do not tolerate being unable to block however.
- The future of forward proxy servers in an http/2 … Adrien de Croy
- Re: The future of forward proxy servers in an htt… Dave Dolson
- Re: The future of forward proxy servers in an htt… Adrien de Croy
- Re: The future of forward proxy servers in an htt… Poul-Henning Kamp
- Re: The future of forward proxy servers in an htt… Adrien de Croy
- Re: The future of forward proxy servers in an htt… Kari Hurtta
- Re: The future of forward proxy servers in an htt… Alex Rousskov
- Re: The future of forward proxy servers in an htt… Adrien de Croy
- Re: The future of forward proxy servers in an htt… Patrick McManus
- Re: The future of forward proxy servers in an htt… Adrien de Croy
- Re: The future of forward proxy servers in an htt… Patrick McManus
- Re: The future of forward proxy servers in an htt… Ryan Hamilton
- Re: The future of forward proxy servers in an htt… Adrien de Croy
- Re: The future of forward proxy servers in an htt… Adrien de Croy
- Re: The future of forward proxy servers in an htt… Adrien de Croy
- Re: The future of forward proxy servers in an htt… Adrien de Croy
- Re: The future of forward proxy servers in an htt… Patrick McManus
- RE: The future of forward proxy servers in an htt… Mike Bishop
- Re: The future of forward proxy servers in an htt… Adrien de Croy
- Re: The future of forward proxy servers in an htt… Alex Rousskov
- Re: The future of forward proxy servers in an htt… Adrien de Croy
- Re: The future of forward proxy servers in an htt… Adrien de Croy
- Re: The future of forward proxy servers in an htt… Adrien de Croy
- Re: The future of forward proxy servers in an htt… Kari Hurtta
- Re: The future of forward proxy servers in an htt… Alex Rousskov
- Re: The future of forward proxy servers in an htt… Tom Bergan
- Re: The future of forward proxy servers in an htt… Alex Rousskov
- Re: The future of forward proxy servers in an htt… Poul-Henning Kamp
- Re: The future of forward proxy servers in an htt… Kari Hurtta
- Re: The future of forward proxy servers in an htt… Tom Bergan
- Re: The future of forward proxy servers in an htt… Adrien de Croy
- Re: The future of forward proxy servers in an htt… Roland Zink
- Re: The future of forward proxy servers in an htt… Ryan Hamilton
- Re: The future of forward proxy servers in an htt… Amos Jeffries
- Re: The future of forward proxy servers in an htt… Adrien de Croy
- Re: The future of forward proxy servers in an htt… Kari Hurtta
- Re: The future of forward proxy servers in an htt… Adrien de Croy
- Re: The future of forward proxy servers in an htt… Kari Hurtta
- Re: The future of forward proxy servers in an htt… Willy Tarreau
- Re: The future of forward proxy servers in an htt… Tom Bergan
- Re: The future of forward proxy servers in an htt… Adrien de Croy
- Re: The future of forward proxy servers in an htt… nicolas.mailhot
- Re: The future of forward proxy servers in an htt… Francesco Chemolli
- Re: The future of forward proxy servers in an htt… Chris Bentzel
- Re: The future of forward proxy servers in an htt… Mark Nottingham
- Re: The future of forward proxy servers in an htt… Alex Rousskov
- Re: The future of forward proxy servers in an htt… Mark Nottingham
- Re: The future of forward proxy servers in an htt… Alex Rousskov
- Re: The future of forward proxy servers in an htt… Willy Tarreau
- Re: The future of forward proxy servers in an htt… Poul-Henning Kamp
- Re: The future of forward proxy servers in an htt… Patrick McManus
- Re: The future of forward proxy servers in an htt… Willy Tarreau
- Re: The future of forward proxy servers in an htt… Kari Hurtta
- Re: The future of forward proxy servers in an htt… Alex Rousskov
- Re: The future of forward proxy servers in an htt… Poul-Henning Kamp
- Re: The future of forward proxy servers in an htt… Roland Zink
- UI | Re: The future of forward proxy servers in a… Kari Hurtta
- Re: The future of forward proxy servers in an htt… Poul-Henning Kamp
- forward HTTPS proxy | Re: The future of forward p… Kari Hurtta
- RE: forward HTTPS proxy | Re: The future of forwa… Mike Bishop
- Re: forward HTTPS proxy | Re: The future of forwa… Alex Rousskov
- Re: forward HTTPS proxy | Re: The future of forwa… Kari Hurtta
- Re: forward HTTPS proxy | Re: The future of forwa… Kari Hurtta
- Re: forward HTTPS proxy | Re: The future of forwa… Kari Hurtta
- Re: The future of forward proxy servers in an htt… Adrien de Croy
- Re: The future of forward proxy servers in an htt… Tom Bergan