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

RE: What will incentivize deployment of explicit proxies?

From: Yoav Nir <synp71@live.com>
Date: Wed, 4 Dec 2013 16:50:10 +0000
Message-ID: <DUB124-W295B61B88DEF198BBD8013B1D40@phx.gbl>
To: Peter Lepeska <bizzbyster@gmail.com>
CC: William Chan (Dz) <willchan@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>
Hi, Peter.
Of course if legal considerations enter into it, that would affect their decisions. Currently I don't know of any different legal status for an explicit proxy vs a MitM proxy.
So here are some incentives, all of which depend on how the feature is implemented in UAs:Just being more ethical.Get the EV indication for websites that have EV certificates.For users configuring their own device (mostly phones, but some laptops) easier, better configuration. The story of why I need to install a CA certificate to make a proxy work is hard to explain. This translates directly to less helpdesk tickets.An easier time managing the proxy certificate - you can upgrade the proxy to 2048-bit RSA or ECDSA without installing a new MitM certificate on all devices.Reduced load - can avoid signing all those fake certificates.Ability to move the proxy out of the data path. A MitM needs to have both the firewall functionality (preventing direct HTTPS) and the proxy functionality on the same machine. With eproxy, the firewall can just redirect, while the proxy can be located on the side. 
That's just off the top of my head. Nobody puts HTTP proxies on the perimeter gateway. There's a good reason for that.
Yoav
Date: Wed, 4 Dec 2013 11:06:50 -0500
Subject: Re: What will incentivize deployment of explicit proxies?
From: bizzbyster@gmail.com
To: synp71@live.com
CC: willchan@chromium.org; ietf-http-wg@w3.org

Hi Yoav,
When I said MITM operator, I was more referring to your customers who deploy your product. If you had two modes of operation in your product -- MITM or explicit proxy -- which would your customers choose? What is the incentive for them to choose eproxy? I think legal considerations may sometimes be one of them.

Thanks,
Peter

On Wed, Dec 4, 2013 at 2:28 AM, Yoav Nir <synp71@live.com> wrote:

On 4/12/13 3:57 AM, Peter Lepeska wrote:






I wonder if MITM proxy operators have any legal concerns about viewing content owners' traffic without their consent or even an indication that the MITM is active. The proxy operators "own" their users' devices presumably but not content owners' data. I think an ideal explicit proxy would allow proxies to make their presence known to content owners.





Hi, Peter



Proxy vendor here. We can't make sweeping statements about legal concerns of proxy operators, because they vary from country to country and from state to state in federated countries.



There are also many variables that may or may not be relevant legally or ethically. One is the question of visibility to humans. A next generation firewall scans the resources going through HTTP and then either transfers them on or drops them. The traffic is never stored and never visible to any administrator. The only thing that is visible is a log saying: "User JohnSmith tried to GET resource https://warez.example.com/downloads/cracked_microsoft_office_2013.exe , which contained virus xxxxxxxxxx".   So that's metadata.  Is that OK?  I don't know. That's why I'm arguing for visibility of the proxy.




Same goes for a Caching proxy. As long as nobody sees the content, what's the harm. If the proxy is used for reading people's emails and social network posts, and forwarding them to the proper authorities if they seem too subversive, the legal and ethical concerns are different. This is the other reason why we need proxies to be explicitly configured. Without that, all of the above proxies look the same.




My company's product does not export HTTPS content. It's strictly a firewall, and there's no usable way to export the data. The problem is that there is no technical way to distinguish this kind of product from one that does export decrypted traffic.




Yoav










 		 	   		  
Received on Wednesday, 4 December 2013 16:50:37 UTC

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