- From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
- Date: Tue, 3 Dec 2013 15:26:49 +0100
- To: "Yoav Nir" <synp71@live.com>
- Cc: "Nicolas Mailhot" <nicolas.mailhot@laposte.net>, "William Chan (陈智昌)" <willchan@chromium.org>, "Roberto Peon" <grmocg@gmail.com>, "HTTP Working Group" <ietf-http-wg@w3.org>
Le Mar 3 décembre 2013 14:36, Yoav Nir a écrit : > I like this discovery process. It's all in HTTP. The only downside is > that it requires plaintext HTTP to work. I'm assuming that > http://awebsite.com should not be the real site that the user is trying > to view, but some specific site that the browser vendor keeps available > just for testing for proxies with HTTP. You can't use the site that the > user used, because that might be HTTPS. Actually, you really need to have http://awebsite.com be the real site because some sites will be available directly and others not and you can't know it before being blocked and receiving the access list (if you decide to trust it) That's why I wrote the initial error requires no authority: the error by itself proves someone is able to intercept the call, you do not have to trust this someone, only the gateway it points you to. So processing this error even if it's not in the tls session is not a security breach (and the simplest this error is the more likely it is to be properly implemented in dumb firefalls) > You will get pushback on #5, though. #5 is really over-engineered, because I am a geek. You can simplify it a lot depending on the choices you want your browser to propose. The only important parts are the three links (access rules, help page, certificate) and yes/no, the rest is browser or extension policy Normal human beings only need to check the "using gateway xxx" occurs on locations they expect xxx to exist, privacy advocates need to see the access list to protest if they don't like them, and only geeks will want to check all the combinations. Regards, -- Nicolas Mailhot
Received on Tuesday, 3 December 2013 14:27:29 UTC