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: Wed, 27 Nov 2013 22:18:15 +0100
Message-ID: <101b0cc7422f4f80844c85253b6c1283.squirrel@arekh.dyndns.org>
To: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
Cc: "Nicolas Mailhot" <nicolas.mailhot@laposte.net>, "Adrien de Croy" <adrien@qbik.com>, "Yoav Nir" <synp71@live.com>, "HTTP Group" <ietf-http-wg@w3.org>

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.


Nicolas Mailhot
Received on Wednesday, 27 November 2013 21:18:45 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:39 UTC