- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Tue, 28 Feb 2017 22:09:35 +0200 (EET)
- To: Alex Rousskov <rousskov@measurement-factory.com>
- CC: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, HTTP working group mailing list <ietf-http-wg@w3.org>, Mark Nottingham <mnot@mnot.net>
> I can only dream of making traction, but I can suggest a different > attack angle: > > 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. Or I am mistaken? When proxy is selected or not by proxy.pac, it is not obvious that is proxy used for particular request. > 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. Proxy needs also then way to report what certificate it got from server. Proxy of course check that certificate, but browsers differiante different certificate classes on UI (that is "Extended Validation" certs produce different location bar). 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 / Kari Hurtta
Received on Tuesday, 28 February 2017 20:10:11 UTC