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

Re: HTTPS, proxy environment variables and non-CONNECT access

From: Robert Collins <robertc@squid-cache.org>
Date: Tue, 16 Jul 2013 22:15:21 +1200
Message-ID: <CAJ3HoZ05kw_0qw7wVA9+-FFiQZUE0tZoM8pTfp8XsP_sMKX-3w@mail.gmail.com>
To: Nicolas Mailhot <nicolas.mailhot@laposte.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 16 July 2013 22:07, Nicolas Mailhot <nicolas.mailhot@laposte.net> wrote:
> Le Mar 16 juillet 2013 11:52, Robert Collins a écrit :
>>> 2. how do you send auth from the client to the proxy in a secure way
>>> without it leaking them outside?
>> I think you mean 'If the origin is an HTTPS origin which uses
>> replayable (e.g. basic) auth, how do you prevent that leaking [vs e.g.
>> how do you authenticate to the proxy itself].
> No, I really meant "how do you prevent web site auth leaking proxy-side,
> and proxy auth leaking web site-side, without assuming one of those auths
> is worthless and can be shared or exposed non-encrypted in the name of
> cutting corners". And that in a world where the only auth most web clients
> will use reliably is basic auth.

If a proxy forwards Proxy-Auth headers on it is either a deliberate
strategy for working in a proxy hierarchy, or buggy as hell :). So I'm
not worried about proxy auth leaking web site-side, it's a non-problem
(or a problem already present in the use of proxies, so unrelated to
the use of proxies to obtain https entities.

The web site auth leaking proxy-side aspect I answered in my prior email.

As for dealing with broken web clients - sure, that is a real concern,
but I have no ideas beyond good specs, and filing bugs/not using bad

Received on Tuesday, 16 July 2013 10:15:48 UTC

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