Re: Semantics of HTTPS

FWIW, I strongly agree with Mark on this. I'm sure that the
other SEC AD agrees too, and reckon that the SEC area as a
whole would also agree, but we can ask if that becomes useful.
A bit more below.

On 08/06/2012 10:23 PM, 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.

The tls WG was offered that option again last week and rejected it
again. If the httpbis WG want to standardise some kind of mitm without
changing TLS then that seems to re-define https to me at least.

Even though mitm hacks exist and people pay for them, the IETF has
actively and repeatedly refused to standardise that behaviour.

Cheers,
S.



> 
> Willy
> 
> 
> 
>

Received on Monday, 6 August 2012 21:33:51 UTC