Re: The future of forward proxy servers in an http/2 over TLS world

On 02/28/2017 01:09 PM, Kari Hurtta wrote:

>> 1. When a client, while talking to a forward proxy, detects and reports
>> a communication error, it SHOULD mention that the proxy was involved and
>> SHOULD mention the address of that proxy.
>>
>> It seems silly to propose that though -- it ought to be common sense,
>> especially for CONNECT errors, especially for folks concerned about user
>> privacy.

> Yes, this looks like common sense. And still no one browser does that.

According to Adrien, FireFox complies with the first SHOULD (at least):
https://lists.w3.org/Archives/Public/ietf-http-wg/2017JanMar/0288.html


> When proxy is selected or not by proxy.pac, it is not obvious that
> is proxy used for particular request.

It is always obvious for the browser. I assume you mean that it is not
obvious for the user, and I agree with that (with cases not limited to
just PAC-driven proxy selection!).

Exposing hidden or obscured proxy usage should be (but is not) a great
motivation for anti-proxy folks arguing that the user must have full
control at all costs. This disconnect feeds conspiracy theories that
those folks prioritize things other than user's informed consent and
control.


>> 2. Clients would also need to support retrieval of HTTPS resources by a
>> forward HTTPS proxy. While such mechanism is already supported by HTTP
>> and TLS, its actual deployment probably requires secure response signing
>> and other fancy stuff that, AFAIK, others have already proposed.

> You means passing https -URLs to proxy for retrieval.

Yes. A.k.a. "GET https://" inside a TLS connection to the proxy.


> Proxy needs also then way to report what certificate it
> got from server.

To be more precise, the _browser_ needs that, but, yes, this is probably
required, and that is exactly why I mentioned secure response signing
(or something like that) as a prerequisite. The proxy would need to
somehow forward origin's response signature or public certificate (at
least). This is where an HTTP extension is required. Everything else is
already supported (at the protocol level) AFAICT.


> In that case location bar probbaly need to be two lines:

> First line tells proxy and certificate status of proxy URL
> Second line tells reported certifcate of server and visited URL

  Third line tells whether the proxy certificate is Transparently Logged
  Fourth line tells the Root CA that signed the proxy certificate
  Fifth line tells the majority stock holder of that Root CA
  Sixth line tells whether that stock holder signed the XYZ pledge
  ...

I continue to resist the temptation to tell browser folks how to do UI.
I am sure that they can build great UIs, and that they do not need this
WG "help" with that. It is a solvable design problem. With enough
motivation, they can solve it.

Alex.

Received on Tuesday, 28 February 2017 20:53:01 UTC