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

Re: "Secure" proxies for HTTP URIs [was: new version trusted-proxy20 draft]

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Thu, 27 Feb 2014 11:14:11 +1300
To: ietf-http-wg@w3.org
Message-ID: <1d4f64cb71145f493cbe27e05d81123a@treenet.co.nz>
On 2014-02-27 06:04, Peter Lepeska wrote:
> That's pretty exciting. It's a shame there's not a better proxy 
> discovery
> mechanism for plaintext HTTP 1.x traffic (maybe just an additional 
> response
> header PROXY-AVAILABLE-AT: https://hostname:port) because it would mean
> forward proxies could immediately provide HTTP2 benefits to their 
> users,
> without having to wait for content servers to adopt HTTP2 and TLS.
> 
> Peter

Which party to the transaction would send that header and how would they 
determine its need to be added?
  * origin server or any reverse-proxy have no idea of forward-proxy 
client-facing capabilities.
  * client is obviously not in-band with the forward-proxy yet.
  * port 80 MITM cannot be trusted that much [1].

There is no 'permanent' version of 305 status code to redirect a client 
to a proxy. But that seems to be what we need. Something like 511 status 
but for proxy detection instead of auth detection.


[1] IIRC one of the reasons for deprecating 305 were attackers utilizing 
305 to redirect port 80 to a local proxy under their control.

Amos


> 
> On Wed, Feb 26, 2014 at 10:55 AM, William Chan (陈智昌)
> <willchan@chromium.org>wrote:
> 
>> Chromium indeed supports this today [1][2], and Firefox has indicated
>> plans for future support, and Patrick seems to have whiteboarded it 
>> out [3].
>> 
>> [1]: https://developers.google.com/chrome/mobile/docs/data-compression
>> [2]: https://sites.google.com/a/chromium.org/dev/spdy/spdy-proxy
>> [3]: https://plus.google.com/+PatrickMcManusDucksong/posts/SnDYxHQoUiq
>> 
>> 
>> On Wed, Feb 26, 2014 at 7:25 AM, Peter Lepeska 
>> <bizzbyster@gmail.com>wrote:
>> 
>>> One question for browser vendors who have said they will not support
>>> HTTP2 over plaintext (Firefox, chrome): will you support HTTP2 when
>>> http-schemed URIs are being proxied via a Secure Proxy?
>>> 
>>> This allows firefox and chrome users to get the performance benefit 
>>> of
>>> HTTP2 at least across the segment between the ua and the proxy for
>>> http-schemed URLs.
>>> 
>>> Thanks,
>>> 
>>> Peter
>>> 
>>> 
>>> On Wed, Feb 26, 2014 at 5:37 AM, Amos Jeffries 
>>> <squid3@treenet.co.nz>wrote:
>>> 
>>>> On 25/02/2014 8:49 p.m., Nicolas Mailhot wrote:
>>>> >
>>>> > Le Mar 25 février 2014 03:58, James Cloos a écrit :
>>>> >> if anyone has a legal requirement to avoid end-to-end encryption, they
>>>> >> MUST accomplish that by avoiding TLS between client and proxy.  Such
>>>> >> requirements MUST not affect the rest of us.)
>>>> >
>>>> > This forbids an http/1 use case and as such is outside the workgroup
>>>> charter
>>>> >
>>>> 
>>>> There is also no sound reason so far presented behind forbidding 
>>>> that
>>>> same use-case in HTTP/2. Just a few implementers choosing not to do 
>>>> it
>>>> for reasons which have all be countered by other implementers who 
>>>> do.
>>>> 
>>>> Also, in my (medium-low) familiarity with such laws TLS or any other
>>>> mechanism used to transport packets to the collection point (proxy) 
>>>> is
>>>> not relevant to the criterion placed upon the ISP. Only the ability 
>>>> to
>>>> accurately and *fully* collect and report is prescribed.
>>>>  End-to-end TLS violates that legal requiremet, TLS-to-proxy does 
>>>> not.
>>>> 
>>>> Amos
>>>> 
>>>> 
>>>> 
>>> 
>> 
Received on Wednesday, 26 February 2014 22:14:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC