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

Re: Explicit Proxy [was: A proposal]

From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
Date: Wed, 20 Nov 2013 10:29:12 +0100
Message-ID: <1d63d50d11df57b2f03d02ecbbc585af.squirrel@arekh.dyndns.org>
To: "Adrien de Croy" <adrien@qbik.com>
Cc: "Mark Nottingham" <mnot@mnot.net>, "HTTP Working Group" <ietf-http-wg@w3.org>

Le Mer 20 novembre 2013 03:26, Adrien de Croy a écrit :
> proxy discovery could almost deserve its own issue.
> A long time ago 305 Use Proxy was deprecated (and apparently it wasn't
> implemented anyway by UA authors).
> Personally I think it (or something similar) could have been useful in a
> restricted (trusted) environment to force a browser to use a proxy that
> they weren't going to get anywhere without using.

A way for proxies to communicate with UAs is certainly required for
explicit proxies to work. And that implies a specific communication stream
with the proxies, to carry prompts, errors, auth, etc in a secure way with
no leakage or spoofing.

305 is universally hated because it's in-stream, so
1. depending on your implementation it does not work with https,
2. or implies breaking TLS,
3. UAs may refuse to display it because of connexion spoofing
4. there is always the risk of leakage if either the intermediary forgets
to remove creds before relaying, or the client sends creds *even when they
are un-needed, just in case* (for example when the client moves to direct

Also you need some sort of connexion table because on a large private
network you don't want to intercept all traffic just in case something
wants to go outside through the proxy. So anyway you look at it you end up
defining magic dns entries that answer with this connexion table to
provide UAs with this info (though it does not need to be the mess wpad
is). If undefined currently I guess people will just intercept google, and
that will sort of work till search market share changes.

Nicolas Mailhot
Received on Wednesday, 20 November 2013 09:29:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:19 UTC