Re: Semantics of HTTPS

On Aug 7, 2012, at 1:21 AM, Adrien W. de Croy wrote:

> 
> ------ Original Message ------
> From: "Willy Tarreau" <w@1wt.eu>
>> Same here :-)
>> 
>> I believe Adrien de Croy has more experience in this area, would be nice to
>> have his opinion here.
>> 
>> 
> I'm flattered, but actually don't have that much deployment experience 
> in MITM outside of the lab.
> 
> I'd be keen to hear from vendors of products that have a few years 
> experience with https inspection.

<vendor hat>

We have several years of experience (as do plenty of others)

Current practice is to have the proxy function as a CA, and sign certificates on behalf of the servers. This MitM attack can only work if the browser trusts this CA. When enterprises deploy such proxies (and pretty much anyone who deploys a "next generation firewall" also deploys a TLS proxy), all users get the warning screens that the server certificate is untrusted. So the HTTPS end-to-end does work. The fact that we've all been trained to click through such warnings is a testament to deployment issues of HTTPS, not to a deficiency in the spec.

Deployments get around those warning screens by having adding the CA certificate to the trust anchor store of the browser. Enterprises do this automatically for Windows machines connected to the domain and using Internet Explorer or Chrome. Users of smart phones, Macs, Firefox, Opera or Linux generally have to do it on their own. There is a privacy issue with a company altering trust settings for the user, but that is not something we can change here. 

The point is that MitM proxies fail as attackers, because (unless they can also configure your browser) they are detected. If you go to one of the countries that deploy country-wide TLS proxies, you will immediately notice this.

</vendor hat>

Yoav

Received on Tuesday, 7 August 2012 07:11:29 UTC