W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

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

From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
Date: Mon, 24 Feb 2014 11:10:45 +0100
Message-ID: <481e0f843a029f43fe2dd291d526f39e.squirrel@arekh.dyndns.org>
To: "Mark Nottingham" <mnot@mnot.net>
Cc: "William Chan (陈智昌)" <willchan@chromium.org>, "Salvatore Loreto" <salvatore.loreto@ericsson.com>, "Peter Lepeska" <bizzbyster@gmail.com>, "Paul Hoffman" <paul.hoffman@gmail.com>, "Patrick McManus" <pmcmanus@mozilla.com>, "HTTP Working Group" <ietf-http-wg@w3.org>

Le Lun 24 février 2014 07:31, Mark Nottingham a écrit :
> On 20 Feb 2014, at 11:40 am, William Chan (陈智昌) <willchan@chromium.org>
> wrote:
>> Let's be clear, these are two different things. There's "secure proxy"
>> which is securing the connection between the proxy and the client. I'm
>> supportive of standardizing this.
> There seems to be a reasonable amount of support for this, and no dissent
> that I've heard.
> What needs to be specified here?

1. how the proxy link can be authentified and re-authentified (when auth
expires) in a secure manner (not the current auth mess that does not work
for tls)
2. some replacement for pac mecanism that uses declarative mode and not a
software language, and is not fixed after web client startup
3. status codes for various proxy events
  1. ??A: rebalance: pac preplacement proxy info with the list of preferred
proxies to use at this moment and sites that can be reached directly
  2. 511: portal → go authenticate or click through this location before
     a. do web clients need a separate re-auth code or will they be smart
enough to replay auth if they receive a new 511 to the same location
after a while? Question for web client people
     b. I assume the location needs to be https using the same kind of
cert as the proxy node
  3. ??B: downgrade → operator only allows h2clr to this site, downgrade
h2 to h2clr or go away (direct has already failed at this stage)
  4. 666: forbidden → proxy operator really does not want you to go there,
life sucks
  5. ??C: dns error → proxy can't find your site
  6. ??D: timeout   → web site does not answer


Nicolas Mailhot
Received on Monday, 24 February 2014 10:11:49 UTC

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