Re: [TLS] MITM Attacks on Client Authentication after Resumption

[Watson Ladd <[e-mail]>]

On Mon, Mar 3, 2014 at 3:32 PM, Salz, Rich <[e-mail]> wrote:
>> both of which were previously noticed in 2009 with the Rex/Ray attack.
>
> Hmm…  Four-plus years is a pretty darn good record, I’d say.

Protocols are not houses. They do not get mildew under the eves. Ants
and termites do not eat the foundation. Unless you are an extreme
intuitionist, TLS was as broken in 2009 as it was today. The pattern
of decision making by this WG is clear: mistakes are noticed, and the
fix doesn't actually cut to the core of the issue. This needs to end.
I'll submit a TLS 2 draft that will be formally verified, easy to
implement (modulo X509), and provide the secure channel semantics that
TLS still doesn't. The big nonsecurity payoff: very few round trips.
(1 if lucky, 2 if not)

>
>> why users should continue to trust TLS with confidential information.
>
> At the risk of being flip or snarky, because it’s the only thing we have.
> Therefore everyone uses it and therefore there are lots more “interesting”
> places for an adversary to attack.  As the old joke goes, I don’t have to
> outrun the bear, I just have to outrun you.

I'm not sure if that's comforting or alarming. As the old saying goes,
if you don't know who the sucker is, it's you. That's why I never play
poker thanks to application of Zorn's lemma. (Well, induction)

>
> At one point, the most common way banks transferred money amongst themselves
> was PGP signed data over FTP. I don’t know if it’s still true. The US
> Federal Reserve requires TLS over direct leased lines for banks doing
> transactions more than $10Million.

There's your answer: the Fed will not trust TLS with amounts over $10
million. Anyone here about to retire? My suggestion: call your broker
and never use their website ever again. Because if the Fed gets robbed
of $10 million they can print more.

>
>> Username password and cookies continue to be widely used in part because
>> client authentication in TLS has not had a good run.
>
> You mean because client certs are not widely deployed, right?  Perhaps some
> name/pbkdf2 is better?

The idea was that the browser would make certs and use them
transparently: this was the idea behind Channel ID. But that got
broken in this latest attack, unless you used ECDHE only.

Password based derivations don't solve the phishing problem, unless
you do something somewhat clever. (mix with hostname, then derive?)
But thanks to backwards compat, a phisher can always get the password.

Sincerely,
Watson Ladd

>
>                 /r$
>
>
>
> --
>
> Principal Security Engineer
>
> Akamai Technology
>
> Cambridge, MA



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin