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

Re: Explicit Proxy [was: A proposal]

From: Adrien de Croy <adrien@qbik.com>
Date: Thu, 21 Nov 2013 00:06:22 +0000
To: "Nicolas Mailhot" <nicolas.mailhot@laposte.net>
Cc: "Mark Nottingham" <mnot@mnot.net>, "HTTP Working Group" <ietf-http-wg@w3.org>
Message-Id: <em6ce87b52-a755-4716-994b-5a4bbbd95407@bodybag>


------ Original Message ------
From: "Nicolas Mailhot" <nicolas.mailhot@laposte.net>
>
>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.
and also support chained proxies.

I think it would be great if the client could know that a message comes 
from the proxy vs the end server.  I'd also be keen to see progress 
messages.

We did a patch to Chromium to test the http progress ID I suggested a 
long time back.  It actually worked pretty well.  You got progress of 
downloading on the proxy, and AV scanning progress.  The visual 
indication of progress actually happening was very successful in 
preventing users from giving up and refreshing.  If a malware was found, 
you then hadn't sent any payload or even final response yet, so could 
then send a page back with a status relating to the incidence of the 
malware.


>
>305 is universally hated because it's in-stream, so
actually I think in-stream is potentially a desirable attribute.  You 
can't necessarily guarantee you'll have any other way to talk back to 
the client.

>1. depending on your implementation it does not work with https,
>2. or implies breaking TLS,
yeah https is a problem.

You can't reliably break into an intercepted TLS connection, since you 
don't know if the client has your signing cert installed or not.  In 
most deployments, where MITM is in use, the clients are configured to 
use a proxy, and intercepting a connection from a client is indication 
the client isn't set to use a proxy, and probably isn't set up with the 
cert.

For that you'd need changes to TLS to effect the same thing.

>3. UAs may refuse to display it because of connexion spoofing
you mean the associated address translation?  Sorry I don't follow.  The 
socket won't get the data back unless the source duplet matches.

>4. there is always the risk of leakage if either the intermediary 
>forgets
>to remove creds before relaying,
bug to just fix?

>or the client sends creds *even when they
>are un-needed, just in case* (for example when the client moves to 
>direct
>connection)
we see this quite a bit.  In fact there seem to be quite a few clients 
happy to send Proxy-Authorization: Basic ... (empty user/pass) in all 
requests regardless of configuration.  Mostly updaters.  I guess they 
share a broken library.

But I don't see how this affects proxy.  Clients making direct 
connections shouldn't leak proxy creds?

>
>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.
That's a network configuration thing.  If an internal router is 
diverting port 80 to the proxy, it should look at the dest IP and not do 
this for intranet sites.

>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.
presuming that connections to google are done at start-up.

Maybe we should just use something to prompt the client to perform 
discovery.  So it would be a 4xx status for http, and something else for 
https.

And something that came up in our support desk today.  To round out the 
discovery feature where you get a client to use a proxy.  It could also 
be useful to have an option to tell a client not to use a proxy (to 
avoid using proxy for intranet for example).  I know this is already 
supported in WPAD, but if the client already connected to the proxy and 
made the request, there's no way to tell the client to connect directly 
instead.

Adrien

>
>--
>Nicolas Mailhot
>
>
Received on Thursday, 21 November 2013 00:06:07 UTC

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