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

I was assuming the forward proxy was in a position to modify HTTP responses
and so it would add the header. But you are right that it's probably better
to use a 3XX status code for this. But in that case, what if the proxy is
optional and the UA decides it wants to go direct? Or what if the UA
doesn't support the new 3XX status code?

Adding the header to responses just says -- "Hey I'm here and if you want
to go HTTP2 Secure Proxy mode with me feel free". Of course, a proxy could
also require its use by blocking port 80 access.

Peter


On Wed, Feb 26, 2014 at 5:14 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:

> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>