W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: I-D Action: draft-ietf-httpbis-tunnel-protocol-00.txt

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Thu, 21 Aug 2014 18:37:04 +1200
Message-ID: <53F59390.2030106@treenet.co.nz>
To: ietf-http-wg@w3.org
On 21/08/2014 4:50 p.m., Adam Rice wrote:
> As a client, why would I add a header to my request that is going to cause
> the proxy to block it? What is the benefit to the user?
> 


Right now there are large numbers of admin who are forced to decrypt TLS
just to determine if the traffic is Skype, HTTPS, your application, or
some attack. This is a nasty situation and getting worse.
 As senders in the TLS arms race improve their use so that it cannot be
hijacked and decrypted these admin are turned towards the last resorts
of a) completely rejecting CONNECT tunnels, or b) configuring an open
proxy, or c) walled garden software environments for clients.


* if the proxy is blocking your traffic because of that header then you
are by definition one of the "bad guys" on that network until unblocked.
Try not to tar your reputation further by forcing issues ;-)

* sending it allows use of your application on networks which do
consider it a "good guy" and would otherwise have a blanket denial on
CONNECT traffic.

* sending it allows proxies to make the required security decisions
without having to hijack and decrypt any traffic.

* if use of this header is picked up widely then we will be headed
toward a situation where more proxies can relatively safely have blanket
rejection on CONNECT traffic omiting it, a lot of current day attacks
will fail, and BCP 188 Pervasive Monitoring stops being pervasive.

Allowing those admin to avoid decryption or open-proxy is a net gain for
both your application and everybody else as well.

Amos
Received on Thursday, 21 August 2014 06:37:49 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC