- From: Roberto Peon <grmocg@gmail.com>
- Date: Tue, 3 Dec 2013 00:28:14 -0800
- To: William Chan (陈智昌) <willchan@chromium.org>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAP+FsNdwRqpvv5i3w93E25M+Z35wDZGRKeot7bQsoiv+9j8OxQ@mail.gmail.com>
On Tue, Dec 3, 2013 at 12:09 AM, William Chan (陈智昌) <willchan@chromium.org>wrote: > On Tue, Dec 3, 2013 at 12:02 AM, Roberto Peon <grmocg@gmail.com> wrote: > >> CDNs, accelerators/caches, traffic-optimizers/traffic-shapers have >> usecases that wouldn't require the browser to give up any confidentiality >> (that the site didn't direct them to do, at least). >> > > I'm going to ignore the CDN case, since I don't think they're explicit > proxies from a UA's perspective (unless I'm misunderstanding). How do you > serve cached content without knowing the URL of the resource? Are you > differentiating between object confidentiality and metadata (URL/headers) > confidentiality here? I think these questions apply to the other use cases > you refer to, but am not completely sure. > As proposed in one of the drafts, if the content-provider provides metadata indicating that a resource can be served from a cache and a means of authenticating it, then the UA can access a proxy via a TLS connection. Only the proxy and the site and the UA thus know what was being requested. If we wish for these requests to be made via HTTP/2, then, for the web-browsing case over the internet, then we'll be extremely likely to be using TLS Since one would like to retain as much confidentiality as possible, sending a request for the resource completely in the clear would not be optimal, even if deploying HTTP/2 in the clear works for the web-browsing case over the internet on port 80. > > >> For enterprises, the new trend is apparently to allow users to use their >> personal devices. These devices would be outside the normal administrative >> chain and would likely cause headaches. >> > > 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. > Enterprises like these have three choices: 1) Disallow access to such devices 2) Force users to install root certs 3) Force users to configure a proxy explicitly. Arguably #3 is the best, from both the enterprise, site and user perspective as setting up an explicit proxy should be easier than installing a root cert for both enterprise and user, and the site now gets signaled about the presence of a proxy. -=R > >> >> -=R >> >> >> On Mon, Dec 2, 2013 at 11:37 PM, William Chan (陈智昌) < >> willchan@chromium.org> wrote: >> >>> Pardon me if this is obvious, but it's not immediately obvious to me >>> what will cause people to use explicit proxies instead of MITM proxies? Who >>> is going to deploy them? The 2 cases I can think of are: >>> >>> (1) People who are using HTTP interception ("transparent") proxies >>> (2) People who are already using SSL MITM proxies >>> >>> In case (1), it appears to me that proxy operators may want explicit >>> proxies, because theoretically those interception proxies provide vital >>> functionality that they don't want to lose if more things go over HTTPS. >>> Because if not, their alternative is to use a SSL MITM proxy, which >>> requires them to own the client devices so they can administratively >>> install additional root certificates. This bears a high cost, both in >>> perceived privacy impact and in requiring administrative maintenance. By >>> this description, I suspect this group probably consists of network >>> operators, like mobile network operators or ISPs or what not. I suspect >>> it's very costly for them to have to administrate customer devices. >>> >>> But I don't see what an explicit proxy will help with here. Is the >>> requirement that there be a way to automagically configure the explicit >>> proxy *and* default to giving up one or more of the confidentiality, >>> integrity, and authentication guarantees normally provided by TLS? I can't >>> see a browser defaulting into letting automatically letting an explicit >>> proxy MITM them. Will it just be opt-in (which, given how much browser >>> vendors "love" presenting UI to end users, is also controversial...)? If >>> so, is that good enough for whoever is deploying these proxies? I have to >>> imagine that's very unsatisfactory for them. What's the vision here? >>> >>> Now, as far case (2), if the proxy operators can already deploy their >>> MITM certs on client devices, then they already own those devices. This >>> sounds like enterprise computing devices or schools or prisons or what not. >>> Now, if they already own the devices on this network, what incentive do >>> they have to adopt explicit proxies? It sounds like they would just lose >>> power. Is there a carrot here? SSL MITM proxies are already transparent to >>> the client and origin server, so I don't see what leverage either entity >>> has here. >>> >>> Would love to hear peoples' thoughts here. >>> >> >> >
Received on Tuesday, 3 December 2013 08:28:41 UTC