Re: Semantics of HTTPS

------ Original Message ------
From: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
>Hiya,
>
>On 08/07/2012 12:37 AM, Adrien W. de Croy wrote:
>
>>
>>what e2e security?  There is none currently with TLS/https.
>>
>
>
>Disagree. There are mitm attacks. They are not ubiquitous.
>
how do we even know that?

Does anyone disagree that these are growing?   It seems to me that more 
and more products are offering this, and certainly more and more of our 
customers are asking for it.

Even if they aren't ubiquitous now, can we say the same about 5yrs from 
now, or 10?

>>>>
>>>>
>>>>The real world REQUIRES inspection capability, for various reasons.
>>>>
>>>>
>>>
>>>
>>>
>>>The real world also REQUIRES lawful intercept. But we (the IETF)
>>>don't do that, and we're right I think. (That is, I agree with
>>>our consensus position.)
>>>
>>>
>>
>>
>>so do I, and this proposal does not affect lawful intercept which would
>>continue to operate in the way it currently does.
>>
>
>
>Your argument was: "real world REQUIRES foo, therefore we MUST do foo."
>That is demonstrably not the case with LI so this part of your
>argument falls.
>

At the moment, our customers, who provide the reason for our existence 
(as a company) pay us, and want this, and will go somewhere else 
otherwise.

offering a service at a proxy which is support for GET https:// is 
something entirely different, and the browser can choose whether it 
will issue that request or not.

If browser authors fail users by not making it clear enough that's 
another issue.

As for whether there's a choice.  There's always a choice.  You can 
maybe make a better choice if you have more information.  If you're 
being spied on, would you rather know or not know?

>>
>>
>>We're only proposing proxying of https, which is done with the knowledge
>>of the client, and is not useful for covert intercepts.
>>
>
>
>Even though based on a bad argument, I don't agree with your last
>conclusion.
>

You're saying it can be visible and yet also covert?
>>>I agree, I'd like to see some more evidence, e.g. rates of prevention of
>>>malware (which commonly uses https to retrieve payload).
>>>
>
>
>The evidence needed would not be "I can do x,y,z at the mitm" but
>rather "I can do x,y,x NN% better at the mitm compared to the endpoint."
>
so you'd rather deploy the "solution" e.g. 1000 times in an 
organisation (and maintain it) than once at the gateway?

You'd be in the minority there I think.  Most people see that only as a 
way to greatly amplify cost and pain.
>>
>>
>>I don't get the question. TLS is designed to combat MITM with or
>>without client certs. That's a fundamental requirement for TLS.
>>
>>
>>
>>
>>yet MITM proxies exist and continue to be deployed presumably
>>successfully.  My question was whether the WG was taking aim at this
>>problem (which would be an escalation of the arms race).
>>
>
>
>"taking aim" is ambiguous so its hard to answer.
>
>What has happened at least a couple of times was: vendor turns up,
>says "our customers need and buy mitm so you need to standardised
>it", tls wg says: no, we're here to provide transport layer
>security not to break that.
>
>I don't see any escalation there nor any arms race. (It is probably
>true that instances of mitm attack are growing in number.)
>

so I take it the WG does not have any plans to make it more difficult 
for people to deploy MITM agents then?

>>>
>>>Feel free to propose a specification that meets your proposed
>>>requirements. That is hard-to-impossible IMO.
>>>
>>>
>>
>>
>>GET https://etc
>>
>
>
>My equally detailed rebuttal is: "That doesn't work." :-)
>
>Next step, you, or someone, writes a real I-D.
>
fair enough.

>>
>>
>>Sure, my point was client-centric.  However, banks are already in this
>>situation.  I use online systems of 3 banks.  None require me to use a
>>client certificate.  Is this just a meteor waiting to hit?
>>
>
>
>I've no idea if your argument is tongue-in-cheek or not. Probably
>better not to respond on that one before that's clear. (Banks issuing
>client-certs is not currently a really tractable approach.)
>
>
my point is that currently (with currently available kit), the only way 
for a bank to prevent MITM is to require use of client certificates (I 
agree it's not a practical solution).

They aren't doing this IME.  Yet I know (directly from bank IT people) 
they are aware of the existence of SSL inspection at proxies.

Therefore they are demonstrating already a trust of the proxy, or more 
to the point designing around it, and not relying on TLS for their 
security but something else (e.g. watchwords, RSA key fobs etc).

If client certs start to be required, I can see a day when people will 
just be required to give their client cert to their proxy operator.  
That would not result in a better situation than we have now.

Adrien
>
>S
>
>
>>
>>
>>They already are demonstrating either ignorance or trust of MITM proxies
>>operated by client organisations.  I won't do them the disrespect of
>>claimimg it's ignorance.
>>
>>
>>>
>>>
>>>
>>>Do we really want to engineer the web so as to allow a company
>>>proxy to prevent payments to the company's favourite bad cause?
>>>That's what's being enabled here. Its a bad plan.
>>>
>>>
>>
>>
>>It can already happen.  If we want to stop it, that's yet another
>>direction to move in.  What we're proposing has no impact on that.
>>
>>Adrien
>>
>>>
>>>
>>>
>>>It might be tractable to figure how to get a user to trust her
>>>employer's proxy for some things, but that's just nowhere near a
>>>full solution IMO.
>>>
>>>Cheers,
>>>S
>>>
>>>
>>>
>>>>
>>>>
>>>>We don't have a system that does not require any trust in any
>>>>party.  We trust the bank with our money, we trust the CA to properly
>>>>issue certificates and to ensure safe keeping of their private keys.
>>>>Most people IME are quite happy to have their web surfing scanned for
>>>>viruses.  I don't see a problem with some real estate on a browser
>>>>showing that they are required to trust the proxy they are using, or
>>>>don't go to the site.
>>>>Otherwise you have to inspect the certificate of every secure and
>>>>sensitive site you go to in order to check if it's signed by who you
>>>>expect (e.g. a CA instead of your proxy).  It's completely unrealistic
>>>>to expect users to do that, and history has shown that educating
>>>>end-users about the finer points of security is not easily done.
>>>>
>>>>
>>>>Adrien
>>>>
>>>>
>>>>------ Original Message ------
>>>>From: "Mark Nottingham" <mnot@mnot.net>
>>>>To: "Willy Tarreau" <w@1wt.eu>
>>>>Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
>>>>Sent: 7/08/2012 9:16:48 a.m.
>>>>Subject: Re: Semantics of HTTPS
>>>>
>>>>
>>>>>
>>>>>
>>>>>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.
>>>>>
>>>>>Cheers,
>>>>>
>>>>>--
>>>>>Mark Nottingham
>>>>>http://www.mnot.net/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>

Received on Tuesday, 7 August 2012 01:23:15 UTC