W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: Yet another trusted proxy suggestion

From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
Date: Thu, 28 Nov 2013 09:25:24 +0100
Message-ID: <bd7b2675ee4cb159d3a2fafe58e688c9.squirrel@arekh.dyndns.org>
To: "Amos Jeffries" <squid3@treenet.co.nz>
Cc: ietf-http-wg@w3.org

Le Mer 27 novembre 2013 23:22, Amos Jeffries a écrit :
> On 2013-11-28 10:18, Nicolas Mailhot wrote:
>> Le Mer 27 novembre 2013 21:58, Stephen Farrell a écrit :
>>> On 11/27/2013 08:40 PM, Nicolas Mailhot wrote:
>>>> Le Mar 26 novembre 2013 21:09, Adrien de Croy a écrit :
>>>>> I don't see any point in using a CONNECT style of approach if you
>>>>> trust
>>>>> the proxy.  What sort of connection is that? If TLS, then why not
>>>>> just
>>>>> use a GET https:// approach.
>>>>> As for using a mandatory proxy on the server end, I don't really see
>>>>> a
>>>>> requirement for that.  People use reverse proxies for sure, but they
>>>>> just appear from the outside to be a server.  I think if we allowed
>>>>> assertion of mandatory proxy use outside a trusted environment (e.g.
>>>>> the
>>>>> user's LAN) then we would have major problems getting it accepted.
>>>> I had the case of an entity that used an authenticating proxy to
>>>> protect
>>>> outside access to their internal webapps. So getting access for our
>>>> users
>>>> to their apps would have required chaining two proxies
>>>> web client on corp1 lan → corp1 outbound auth proxy → Internet →
>>>> corp2
>>>> inbound auth proxy → webapp on corp2 land
>>>> And of course corp1 and corp2 secrets were not shared, only users
>>>> with
>>>> dual affiliation had a login on both proxies.
>>> I'm not sure how that actually works with http/1.1 - does it
>>> really?
>> I freely admit we could not get it to work which made those
>> dual-affiliated users greatly cross with IT. We would definitely be
>> interested in upgrading our hardware to http/2 if it could solve such
>> use-cases, we do not enjoy making users miserable.

> HTTP auth framework is quite flexible. Squid can configure exactly this
> in any one of several ways:

And those all suppose that either corp2 changes its proxy not to use proxy
auth (tells a lot about how broken http1 auth is) or that corp1 takes over
credential management for dual-affiliated users (which won't really work
since the whole point is to have corp1 and corp2 credential organisations
ignore each other, since they both target their own organisation


Nicolas Mailhot
Received on Thursday, 28 November 2013 08:26:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:20 UTC