RE: What will incentivize deployment of explicit proxies?

Hey, you asked about operator incentives

נשלח מה-Windows Phone שלי
From: Peter Lepeska<>
Sent: ‎12/‎4/‎2013 19:06
To: Yoav Nir<>
Cc: William Chan (陈智昌)<>; HTTP Working Group<>
Subject: Re: What will incentivize deployment of explicit proxies?

7. Indication that proxy server intends to view data in the clear.
8. Ability for content server to say no. #7 and #8 amount to content server
9. Improved experience for unsupported devices.


On Wed, Dec 4, 2013 at 11:50 AM, Yoav Nir <> wrote:

> 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:
>    1. Just being more ethical.
>    2. Get the EV indication for websites that have EV certificates.
>    3. 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.
>    4. 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.
>    5. Reduced load - can avoid signing all those fake certificates.
>    6. 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:
> To:
> CC:;
> 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 <> 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
> 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 18:01:51 UTC