Re: Semantics of HTTPS

On Aug 7, 2012, at 12:23 AM, Willy Tarreau wrote:

> On Mon, Aug 06, 2012 at 04:16:48PM -0500, Mark Nottingham wrote:
>> 
>> On 06/08/2012, at 4:14 PM, Willy Tarreau <w@1wt.eu> wrote:
>> 
>>>> Right. That's a big change from the semantics of HTTPS today, though; right
>>>> now, when I see that, I know that I have end-to-end TLS.
>>> 
>>> No, you *believe* you do, you really don't know. That's clearly the problem
>>> with the way it works, man-in-the middle proxies are still able to intercept
>>> it and to forge certs they sign with their own CA and you have no way to know
>>> if your communications are snooped or not.
>> 
>> It's a really big logical leap from the existence of an attack to changing
>> the fundamental semantics of the URI scheme. And, that's what a MITM proxy is
>> -- it's not legitimate, it's not a recognised role, it's an attack. We
>> shouldn't legitimise it. 
> 
> That's clearly what I'm suggesting : offer a clean way to have a proxy inspect
> contents with the users' consent in the browser policy (using GET https://) or
> ask for a tunnel to be established, assuming it should be end-to-end. There
> will be no more solution than today to detect there's an MITM, but at least
> there will be far less incentive for product authors to do that if it's only
> for a handful of trustable websites.
> 
> At the moment the state of affairs has created MITM proxies and we'd better
> get rid of them by offering a solution to the problem they try to solve.

I don't think this is actually getting rid of them. It really depends on how you define "MitM". If a user connects to facebook, they naturally expect their traffic to go straight to facebook, and if notice the little padlock icon, they expect this connection to be confidential. They don't expect third parties to be reading this, so any third party that does is a MitM.

Whether you configure a sniffing CA, or a "trusted proxy" makes no difference. Making it part of the protocol makes no difference, because the user's privacy is not affected by whether the proxy behavior is "standardized" or a "hack". The implications are the same.

The proposal that Stephen mentioned was rejected by TLS was not intended to make privacy better or worse than the current situation, not does it change the implications of having a MitM. This proposal also does not change things.

Yoav

Received on Tuesday, 7 August 2012 07:00:00 UTC