Re: [therightkey] Basically, it's about keeping the CAs honest

[Tom Ritter <[e-mail]>]

On 16 February 2012 00:24, Martin Rex <[e-mail]> wrote:
> What these MITM proxies are doing is _completely_and_thoroughly_
> subverting the entire purpose of the TLS protocol.  They're doing
> it not by exploiting weaknesses in the TLS protocol itself
> (at least prior to rfc5746), but instead, by exploiting a long-standing
> fatal design flaw in the security in the existing TLS X.509 PKI trust model.
>
> Those who want a protocol for encrypted communication that can be
> arbitrarily MITMed should design themselves such a protocol.
> Expecting the IETF to support continued exploitation of a serious
> weakness in a security architecture that is the exact opposite of
> its stated design goal is inappropriate for the IETF.

I think it's important to remember that whatever the TLS, DANE, and
any other working groups come up with - there will be an army of
people waiting to break the very first implementation, and they will
do so.  I will be one of them.

No matter what Firefox and this working group come up with, I will
break it locally, so I have a non-nagging TLS MITM.  Even if I have to
go in and modify the browser source code itself.

Why? Because I test web apps!  I need a MITM tool like Burp,
Fiddler[0], or Mallory[1] to let me modify the traffic after it leaves
the browser, before it leaves the machine, so I can test the inputs
(form fields, headers, methods, and whatever else) the server accepts.
 That simple, that benign, that necessary, and yet entirely able to be
re-purposed for evil.

On 16 February 2012 08:01, Phillip Hallam-Baker <[e-mail]> wrote:
> Here we are all agreed that it is generally a bad thing for there to
> be this particular hole. That is not the issue. The issue is whether
> ignoring the fact that there are regulatory requirements for this
> capability and not supporting them results in a better or a worse
> outcome for users.
>
> So far the evidence suggests that refusal to consider them has
> resulted in a worse outcome.

I agree, but I don't really understand why everyone's arguing.  It all
seems to be tangent to the purpose of all the working groups I've
seen, because ultimately, it's left at the discretion of the
implementations.

A:"We shouldn't enable MITM under any circumstances!"  B:"Okay, do you
want to outlaw local trust databases?" A:"No, that's implementation
details."  B:"Yea but.... that's how MITM works."
or
A:"We shouldn't talk about MITM in the protocol!" B:"Okay, but people
are going to do it. Maybe we should have guidelines so users are
notified?" A:"No!" C:"Isn't that up to the browser?" B:"Oh, yea."

The only argument I could see worth debating is somehow _enabling_
MITM in the TLS protocol *itself*.  And not only do I think that's a
huuuge change, super-dangerous, I also think it's entirely
unnecessary, because we already have a viable, working MITM solution:
local trust stores.

It seems to be a simple question: Will whatever "CA
Solution/Improvement" we come up be expected to override local,
user-set (or corporate IT-set) policy?  If no, MITM will work - don't
worry about it.  If so, how do you expect to accomplish that, when I
control everything on my machine?[2]

-tom


[0] Burp and Fiddler are proxies designed for fiddling with HTTP
requests and responses
[1] Mallory is designed to muck about with raw TCP packets
[2] It *is* worth noting that the local policy engine/mechanism then
becomes ripe for attack, and instead of compromising CAs, we'll see
attacks that exploit bugs in it.  But, we can deal with that.