Re: Semantics of HTTPS

Additionally, such a plan has to be actually implemented in browsers, and I haven't heard any support from that quarter; more the opposite, in fact. 

Sent from my iPhone

On 06/08/2012, at 6:18 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

> 
> Hiya,
> 
> Some points below on what is a tricky issue but one where I think
> the status quo is better than the offered alternatives.
> 
> On 08/06/2012 11:39 PM, Adrien W. de Croy wrote:
>> 
>> I think we need to be clear what we are doing when we apply logic such as
>> 
>> 1. TLS / HTTPS was not designed for inspection
>> 2. therefore any inspection is a hack
>> 3. therefore we should not allow/sanitise it
>> 
>> One could argue that 1. was a design failure (failure to cover all
>> requirements), and that it should just be fixed. 
>> One could also argue that hacks have as much right to be accepted as
>> anything else.  They exist for a purpose.
> 
> Yep. To break e2e security. But that's not a very defensible
> purpose in an organisation (the IETF) where the e2e argument is
> taken seriously.
> 
>> 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.)
> 
> I'd encourage folks who care about this to go look back at the raven
> list arguments (if you've plenty of time;-) [1] I personally think
> that was the IETF at its best - deciding a technical position on
> a technical basis even in the face of non-trivial political and
> commercial pressure.
> 
>   [1] http://www.ietf.org/mail-archive/web/raven/current/maillist.html
> 
> (I hope folks don't try score points by selective quoting from that
> archive - pretty much all opinions are represented there as I recall;-)
> 
>> We can either ignore that requirement, and carry on with our arms race,
>> or come to some mutual agreement on how to deal with the very real and
>> in many (if not most) cases entirely legitimate requirement.
>> 
>> At the moment, it's starting to look uglier and uglier.  Major sites
>> such as FB / Google move to TLS (maybe just to reduce blockage at
>> corporate firewalls?).
>> 
>> I can't count how many customers ask me a week how to block https sites
>> esp FB, gmail, youtube and twitter.  It's pointless arguing whether
>> someone should do this or not, we don't pay for their staff down-time.
>> 
>> So we have MITM code in the lab.  Many others have deployed already.
> 
> Well just block those sites if you must. I don't see why inspection
> is somehow better. I do see that some people might think inspection
> is better, but if that's a falsehood then no conclusion can be drawn.
> (False => anything, logically.) Evidence of the effectiveness of
> MITM inspection (vs. endpoint mechanisms) would be good, but seems
> to be missing.
> 
>> Next step if a site wants to do something about that is maybe start to
>> use client certificates. 
>> Anyone here from the TLS WG able to comment on whether there are plans
>> to combat MITM in this respect?  
> 
> I don't get the question. TLS is designed to combat MITM with or
> without client certs. That's a fundamental requirement for TLS.
> 
>> It's interesting to see the comment
>> about recent TLS WG rejection of support for inspection.
> 
> Recent and repeated. I think this is maybe the 3rd time.
> 
>> At the end of the day, the requirement is not going away, and it's only
>> my opinion, but I think we'd get something that
>> a) works a lot better (more reliably)
>> b) better reflects reality and allows users to make informed choices
> 
> Feel free to propose a specification that meets your proposed
> requirements. That is hard-to-impossible IMO.
> 
>> if we actually accepted the reality of this requirement and designed for
>> it.  IMO b actually results in more security. 
>> As for the issue of trust, this results in a requirement to trust the
>> proxy. 
> 
> You left out an important thing: it requires sites (e.g. a bank)
> to trust proxies the site has never heard of with the site's
> customer data, e.g. payment information.
> 
> 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 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 Monday, 6 August 2012 23:30:48 UTC