- From: Adrien de Croy <adrien@qbik.com>
- Date: Sun, 05 Mar 2017 21:30:52 +0000
- To: "Roland Zink" <roland@zinks.de>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
------ Original Message ------ From: "Roland Zink" <roland@zinks.de> > >A proxy is an additional 3rd party which I may trust and want to use >(for some service it provides) or I have to use, which is the bad case. >In the first case I don't necessarily need the information about all >the proxies involved but of cause I want the to know about the latter >case. > So you're a 6yo at a school, and your school forces you to connect to the internet through a proxy so they can block unsavoury/inappropriate content. Please explain why this is "bad"? I think we need to be careful not to let personal prejudices about what constitutes good or bad drive protocol standards. There's a lot of prejudicial language on this list especially about interception, MitM (whether of plaintext http or https). Sure I can sympathise with a view that a foreign agent covertly intercepting and accessing data is "bad", but I can also see legitimate uses for interception, such as protection of children, protection of intellectual property (DLP) etc, which is "good". Fundamentally a company that employs people who have internet access will decide whether it will block or not. Many will, and it is their unalienable right to control use of their property / resource. At the moment the move to https everywhere and the abysmal user experience of this in most browsers means that there is a lot (and increasing amount) of time wasted in organisations dealing with misleading/false error messages in browsers. As a first step, I believe something needs to be done about the error messages, and ongoing we need to deal with how to block in a way that does not reduce user security, even if we don't move past CONNECT as a way to access https. Whether that requires trust of a proxy or something else is another matter. When I say trust, that comes with consequences, such as believing the proxy when it asserts something. This is a consequence of trusting it. Adrien > >Is it really bad when a browser allows me to trust a proxy? > >Regards, >Roland > > >Am 28.02.2017 um 22:26 schrieb Poul-Henning Kamp: >>-------- >>In message <20170228200936.C5AB71F5E9@welho-filter3.welho.com>, Kari >>Hurtta writes: >> >> >>>Yes, this looks like common sense. And still no one browser does >>>that. >>I think common sense can be summarized as follows: >> >>1. If any proxy is involved, both the client and server should know >> that, so that they can judge for themselves to what extent they >> want to trust the proxy. >> >>2. A legitimate proxy has no reason to try hide its own existence >> or to deliberately reduce the security, privacy or integrity of >> the communication, beyond what is required for doing its job. >> >>3. It should be as hard as possible to insert and hide an ilegitimate >> proxy (=MITM attack) which undetected can impact security, privacy >> or integrity of the communication. >> >>On the client side the only politically reasonable and neutral >>solution is to announce the precense of a proxy by inserting a >>prominent identification of it above the address bar, so that the >>user sees: >> >> BIGCORP Inc. Proxy (Contact IT/Bill x1234) inspects this connection >> >> https://mybank.com/ >> >>Or as it may be: >> >> ELBONIA Government National & Child safety Proxy inspects this >>connection >> >> http://bikeshed.org >> >>The "proxybar" should be suitably decorated to indicate if the >>connection to the proxy has any kind of privacy and if there is any >>reason to think that the proxy really is who it claims to be. >> >>The current "political" stance by the user agents means that literally >>millions of people are behind proxies, legitimate and ilegitimate, >>without knowing it or being able to see it, without significant >>X.509-skillz. >> >>As for the political fight for a fundamental human right to privacy: >> >>More people would probably pay attention, if they could clearly see >>who tried to mess with their communication. >> > >
Received on Sunday, 5 March 2017 21:31:31 UTC