- From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
- Date: Tue, 3 Dec 2013 14:16:33 +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 12:24, Yoav Nir a écrit : > On 3/12/13 12:02 PM, Nicolas Mailhot wrote: >> Le Mar 3 décembre 2013 09:09, William Chan (陈智昌) a écrit : >> >>> I agree using personal devices would likely cause headaches. But you're >>> not >>> saying explicit proxies solves this somehow, do you? If so, I missed >>> it. >> Explicit auto-configured proxies allow plugging in devices which have >> not >> been mastered by the IT department. They don't require the user to hunt >> for the MITM certificate, or the pacfile that enables external >> communication on corporate premises. >> > I don't want to get too far down the UX rat-hole, but I wonder what > steps 3-9 in the following story look like > > 1. Got myself a new tablet/laptop/SmartWig > <http://gizmodo.com/sonys-play-for-elderly-tech-fans-a-wearable-smart-wig-1471023561>. > 2. I brought my new device to work (where there is this new HTTPS proxy) > 10. I can now surf to https://www.paypal.com *and* I see the green EV > indication > > What steps does the user need to take. 1. get a web client 2. try to access http://awebsite.com 3. get http error see-gateway https://somegateway.com/ (either single entry or list of gateways) no tls is needed for the error, the only authority is ability to intercept or block the call (or just get blocked with no return and try https://somegateway.com/ that was hinted at in dns, dhcp or preconfigured in the web client) 4. ask https://somegateway.com/ for http://awebsite.com in ingoing-http2-mode ingoing-http2-mode being one of in-clear, in-clear-with-anti-tampering, encrypted-to-gateway, end-to-end-encryption receive an http/2 frame with (mandatory) gateway name (optionnal) allowed ingoing-http2-mode for http://awebsite.com (if disagreement with the browser and do not want to push full access rules) (optionnal) login request (optionnal) access rules list: list of rules like from ip/ips to website/domain/ip list use (gateway-list in ingoing-http2-mode) (DIRECT) to website/domain/ip list use (gateway-list in ingoing-http2-mode) (DIRECT) from ip/ips … otherwise use (website/domain/ip list) (direct) (optional) location of help page (terms of use, etc) (imho regardless of the ingoing mode chosen login if required must be secured) 5. Prompt the user: Accept using gateway-name to access http://awebsite.com/ and other web sites in ingoing-http2-mode ? [check reformatted access rules] [see help page] [see certificate] [ ] Prompt for other web sites and security modes ( ) only for this session ( ) all the time (*) only from here ( ) everywhere [Yes] [No] 6. Assuming the user clicked yes show the eventual login prompt and proceed 7. every time connexion uses a gateway show using gateway-name transient message + some widget that gives access to gateway chain in use with properties (so user can detect its coms are intercepted when they're not supposed to be) 8. no opinion if its better to apply the access list blindly or only when direct connection fails, it's more a hint that anything else but trying direct on every object on restricted networks is going to be expensive Other messages the gateway needs to insert in the stream at any time Refused (code + optional pretty explanation page) Rebalance other-gateway-list (re)login (login expired or previous web sites allowed without login) Access rules change (new list) Regards, -- Nicolas Mailhot
Received on Tuesday, 3 December 2013 13:17:13 UTC