W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: What will incentivize deployment of explicit proxies?

From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
Date: Tue, 3 Dec 2013 14:16:33 +0100
Message-ID: <259470c969598db776d90c27847b4c7a.squirrel@arekh.dyndns.org>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:20 UTC