Intercepting proxies - yet again

Hi all

a long time ago I raised this as an issue, in the context of the 
deprecation of status 305.

Around that time, we started trying to lead customers away from 
deploying our proxy in an intercepting fashion towards explicit 
configuration of clients by whatever means.

However it's just not working out.  In fact we have clients moving the 
other direction; abandoning explicit proxy use to instead use 
intercepting deployments.  Interception as you know creates problems for 
proxies that wish to use HTTP authentication to clients.

Anyway this is just our customers.  There are also many many ISPs that 
use intercepting proxies, and there are increasing reasons for an ISP to 
do so, as bandwidth consumption increases, so do the incentives to run 
an intercepting caching proxy - especially in countries where a high 
proportion of traffic is still international (e.g. here in NZ).

Interception remains the only viable option in a lot of cases, and in 
fact I think its use is growing.  WPAD is not universally supported or 
uniformly implemented, AD GPOs aren't either. Creating dependencies on 
DHCP or DNS to discover proxies leads to failures, even for those sites 
where it makes sense to try.

So I hate to think how many people are going through intercepting 
proxies today. Probably in the hundreds of millions. Does anyone have 
any estimates for this?

In any case, I think there are enough affected users that we should not 
ignore them, not for HTTP/1.1 nor HTTP/2.0. I think it's not a 
justifiable stance to continue to ignore this in the specs.  There needs 
to be some guidance, and some design done to make the situation better.

There have also been long discussions on this list about intercepting 
SSL etc.

IIRC 305 was deprecated for "security reasons".  However I can (maybe 
naively) imagine a scenario where something telling a client it needs to 
use a proxy could be done "safely".

So, I propose that there be a way for an intercepting proxy to

a) notify the client explicitly that it is being intercepted
b) inform the client as to policy about access through the intercepting 
proxy (e.g. you must use this ip:port as a proxy to get any further).

This would permit deployments where intercepting proxies can "upgrade" 
clients to explicitly using a proxy by responding to all intercepted 
connects with this sort of response.

The UA could then offer a user experience such as:

"The proxy server at x.x.x.x:p asserts it has intercepted your 
connection, and you must use it as a proxy to proceed".
[x] trust this proxy in future
[ OK, use it ] [ cancel ]

I know this is a can of worms for security, but:

* client should refuse to use the proxy if it's not on the same network 
as the client, or not on a trusted network.
* it is true that the agent that had the capacity to intercept the 
connection has the capacity to reject all requests until the client uses 
it as a proxy.
* it is true that the client still gets to choose whether it is prepared 
to do this
* it's no worse than certificate warnings.

this would provide an opportunity to solve this issue in one place at 
the point of interception, which I believe is the best place for several 
reasons, not the least reliability of deployment due to removal of 
dependencies on external systems (c.f. DHCP or DNS for WPAD).

Anyway, what do people think, is there any point proceeding with this to 
say I-D?

Regards

Adrien