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

nicolas.mailhot@laposte.net Fri, 17 February 2017 12:17 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 BC8221299DB for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 17 Feb 2017 04:17:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.002
X-Spam-Level:
X-Spam-Status: No, score=-7.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=laposte.net
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 tQjgNZ5l_Omd for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 17 Feb 2017 04:17:55 -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 791AB1299E1 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 17 Feb 2017 04:17:55 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cehQv-0004Ja-DI for ietf-http-wg-dist@listhub.w3.org; Fri, 17 Feb 2017 12:14:41 +0000
Resent-Date: Fri, 17 Feb 2017 12:14:41 +0000
Resent-Message-Id: <E1cehQv-0004Ja-DI@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <nicolas.mailhot@laposte.net>) id 1cehQp-0004Io-9L for ietf-http-wg@listhub.w3.org; Fri, 17 Feb 2017 12:14:35 +0000
Received: from smtpoutz13.laposte.net ([194.117.213.172] helo=smtp.laposte.net) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <nicolas.mailhot@laposte.net>) id 1cehQi-000737-PC for ietf-http-wg@w3.org; Fri, 17 Feb 2017 12:14:29 +0000
Received: from smtp.laposte.net (localhost [127.0.0.1]) by lpn-prd-vrout001 (Postfix) with ESMTP id CD71B4E4F370 for <ietf-http-wg@w3.org>; Fri, 17 Feb 2017 13:14:05 +0100 (CET)
Received: from smtp.laposte.net (localhost [127.0.0.1]) by lpn-prd-vrout001 (Postfix) with ESMTP id AE0004E4E709 for <ietf-http-wg@w3.org>; Fri, 17 Feb 2017 13:14:05 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=laposte.net; s=mail0; t=1487333645; bh=l2FDS5VAqXHVYXvqPwwr0oAAt8Qx2vPUMqYMU8lcmXQ=; h=Date:From:To:Cc:In-Reply-To:References:Subject; b=XtqtGak06wL7Vt1vqZeyCBvVZSzG35pAbylPhTY8qvUxg3J24/8b31bdnREiI5tE4 qZ5I2AhEOui4wI9jn9USHLI3oRQ9ldW5lnkLCfdslmrX9Mq0narm8na0vGVK+N+rea vcdpGNyhRJyvtJLpGLFw6+8m9HLOAcaeJ5w2SCEfEjemaA3bGhptznZV6xVZLF393z lk3adwfoX1bxDkior04UqkacMh/TeYpuDzPmBUE0AvFlKQ180Z2E369dKg93h678ff pASqjZRZ/IGcLUQMLdf9synTkN3z98JmPJ1Ve+ZoXQqaQLXPtTGfngancu+P9k4xDU pI5TXvfhn94/w==
Received: from lpn-prd-mstr088.laposte (lpn-prd-mstr088 [10.128.59.114]) by lpn-prd-vrout001 (Postfix) with ESMTP id 92BEB4E4DE91; Fri, 17 Feb 2017 13:14:05 +0100 (CET)
Date: Fri, 17 Feb 2017 13:14:05 +0100
From: nicolas.mailhot@laposte.net
To: Tom Bergan <tombergan@chromium.org>
Cc: Adrien de Croy <adrien@qbik.com>, ietf-http-wg@w3.org
Message-ID: <44039619.275607.1487333645445.JavaMail.zimbra@laposte.net>
In-Reply-To: <CA+3+x5GV9MdYOP3gHLABe+=GVVKf7ugbMWHquuzVHGCbwY-s5w@mail.gmail.com>
References: <emde1bfa93-84c0-49f7-83a4-b9bed24e0276@bodybag> <CA+3+x5GV9MdYOP3gHLABe+=GVVKf7ugbMWHquuzVHGCbwY-s5w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [192.196.142.91]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF51 (Win)/La Poste)
Thread-Topic: The future of forward proxy servers in an http/2 over TLS world
Thread-Index: J3tNg4LJfV+9zcLXcZlli0oDEMHF/w==
X-VR-SrcIP: [192.196.142.91]
X-VR-FullState: 0
X-VR-Score: -100
X-VR-Cause-1: gggruggvucftvghtrhhoucdtuddrfeelhedrtdeigdefkecutefuodetggdotefrodftvfcurfhrohhf
X-VR-Cause-2: ihhlvgemucfntefrqffuvffgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhs
X-VR-Cause-3: ucdlqddutddtmdenucfjughrpeffhffvkfgjfhfugggtgfhiofhtsehtjegttdertdejnecuhfhrohhm
X-VR-Cause-4: pehnihgtohhlrghsrdhmrghilhhhohhtsehlrghpohhsthgvrdhnvghtnecukfhppedutddruddvkedr
X-VR-Cause-5: heelrdduudegpdduledvrdduleeirddugedvrdeludenucfrrghrrghmpehmohguvgepshhmthhpohhu
X-VR-Cause-6: thdphhgvlhhopehlphhnqdhprhguqdhmshhtrhdtkeekrdhlrghpohhsthgvpdhinhgvthepuddtrddu
X-VR-Cause-7: vdekrdehledruddugedpmhgrihhlfhhrohhmpehnihgtohhlrghsrdhmrghilhhhohhtsehlrghpohhs
X-VR-Cause-8: thgvrdhnvghtpdhrtghpthhtohepihgvthhfqdhhthhtphdqfihgseiffedrohhrgh
X-VR-AvState: No
X-VR-State: 0
Received-SPF: pass client-ip=194.117.213.172; envelope-from=nicolas.mailhot@laposte.net; helo=smtp.laposte.net
X-W3C-Hub-Spam-Status: No, score=-3.9
X-W3C-Hub-Spam-Report: AWL=-1.857, BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1cehQi-000737-PC 8400e73f39f7e985f24df34e96c4a807
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/44039619.275607.1487333645445.JavaMail.zimbra@laposte.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33576
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>

Hi,

I'll answer once, because every single long timer in the list is sick to death of browser/privacy people asking "why" every couple of months, with accusing/unkind/moralistic vocabulary, and then going AWOL as soon as the presented facts do not go their way.

Aside from special professions where monitoring and eventually blocking is a legal requirement, blocking at the proxy level is just a matter of network scale for corporations.

The biggest your private network is, the less you are able to control individual endpoints, because there are too many of them, they break down and are replaced all the time, and they are increasingly diverse, from desktops to laptops to tablets to smartphones to printers to appliances to the connected lightbub some idiot brought to impress his boss with software-controlled colours. Plus if your org is big enough you get visitors with their own hardware, BYOD hardware to (supposedly) cut IT support costs, etc, etc. So forget about any mechanism that requires installing specific software addons endpoint-side.

The biggest your private network is, the more likely you have somewhere a business-critical function deployed on a badly secured system (mistakes happen, contractors can be incompetent or careless, gray IT is a fact of life). So you need to protect this network, it's not just an Internet extension.

The biggest your private network is, the more likely *bignumber* of users slacking and watching cat videos on youtube will translate in expensive network upgrades, including paying civil works to lay down new dark fiber to your premises. Civil works that business units will refuse to pay, since no one managed to write a convincing business plan that includes watching cat videos so far. (The ways CDNS and systematic encryption have killed any hope of caching at the gateway does not help either). As a bonus the very same business units will hang you dry because you let this traffic saturate links that were needed for business functions.

Educating people properly, fixing every system, getting IT support to audit, configure and fix every possible endpoint, has prohibitive costs, and would bring down the company velocity to a halt. Not every company can afford a workforce composed exclusively of bright-eyed responsible up to date computer scientists. Not every company can afford to design its own hardware and desktop software that it is sure of (besides, don't forget the lightbulbs). Most companies can not airgap every critical system (the other armchair answer to security problems). There are too many of them, they change all the time, they are all networked right and left.

So you try to limit the breakage, by forcing all your outbound traffic through a gateway, and blocking at that gateway anything likely to generate non-business-related high level of traffic, and anything linked to security attacks. Which requires subscribing to expensive web reputation services, listening hard to the notifications of your country's cyber command (aka your spooks), etc

If you're nice you can rate-limit non business-critical traffic instead of blocking it, but that still requires identifying this traffic at the gateway (layer-7 URL matching, because who wants to track what is akamai's, youtube's, etc ip plan today).

So there *is* blocking at the gateway level, there *will* *be* blocking at the gateway level, the question is not whether this blocking should exist or not, but if the user experience can be made less miserable than it is today because of unilateral browser changes.

Regards, 

-- 
Nicolas Mailhot