Re: What will incentivize deployment of explicit proxies?

On 7/12/13 4:13 AM, Adrien de Croy wrote:
> One thing.
> I think it would be a bit of a push to try to force companies that 
> want to deploy a MitM to obtain a CA-issued signing cert for signing 
> the spoofed certs.  Many will choose a local CA-issued (e.g. the AD CA 
> server) but also many will choose self-signed certs for this.

To be clear, when we're talking about explicit proxy, we mean an 
alternative to the MitM, one that does not require spoofing certs. The 
client would connect directly to the proxy, validating the proxy 
certificate, and then ask the proxy to GET or POST to the original 
server. So the proxy certificate is a regular DV or EV certificate that 
CAs are willing to issue cheaply. So, not particularly onerous.
> So presuming that the proxy will be authenticated may not be that 
> reliable.
> Also I don't think lay people really will have much of a clue what TLS 
> means.

Perhaps, but they do know what encryption is for, and they (hopefully) 
understand why you don't allow someone you don't trust to see your 
personal information, credit card number, etc.

> I think it's reasonable to take a precautionary default stance as 
> proposed (block until allowed).  But each browser vendor will probably 
> make their own decision as to what the default is.
> I imagine some browser vendors may wish to allow in some environments 
> that this can be centrally managed?  e.g. by Group Policy.  This then 
> may take away the warning (although a browser could still put up a 
> warning to let people know the decision had already been made for them 
> by their sysadmin).  That's why I think some permanent visual 
> indicator could be useful.  Even if it had a question mark somewhere 
> in it so people could see why they were seeing that indicator.
> I think though browser vendors will get serious complaints if there's 
> no quick easy way for a user to say yes use the proxy. Each user will 
> become a support call.
> But these are all browser UI decisions.
> We are talking about the protocol here.  I don't think we should pare 
> back the protocol to remove choice for users.  Browsers can remove 
> choice by deciding what choice to make on behalf of the user, we don't 
> have to take the choice away in the protocol.  That leaves zero wiggle 
> room if it turns out we made the wrong choice. Who knows what basis a 
> browser may use to choose a default action.  E.g. depending on where 
> the proxy is, what site is being visited, some external information 
> etc the default may vary and in unresolvable situations the user can 
> be asked.

Agree. All we can do in protocol is to inform the client that a 
mandatory proxy exists (similar to today's captive portal), and provide 
a protocol for connecting to such a proxy and moving information between 
client, server and proxy.  What implementation will do with this 
information, and how they will present some or all of it to the user is 
up to the browser vendor.


Received on Saturday, 7 December 2013 05:30:11 UTC