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

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

Regards,

-- 
Nicolas Mailhot

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