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

Regards,

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