Re: [TLS] RFC4492bis - Removing ECDH

[Ilari Liusvaara <[e-mail]>]

On Wed, Jan 14, 2015 at 08:02:39PM +0800, Michael Clark wrote:
> On 11/1/15 1:14 pm, Ilari Liusvaara wrote:
> > On Sun, Jan 11, 2015 at 10:17:09AM +0800, Michael Clark wrote:
> >>
> >> There is a more subtle pass through case where handshake messages can be
> >> tampered with (without access to a CA, just an Internet coffee bucks
> >> WiFi tap). Allows attacks such as editing cipher lists and any other
> >> associated handshake metadata (curve format extensions, switching on
> >> compression) that are not properly authenticated. Until I am certain
> >> they are completely mitigated I remain skeptical.
> > 
> > This attack won't work.
> > 
> > - TLS 1.3: The messages are hashed into hMS, so you can't decrypt the
> >   rest of the handshake due to having wrong keys.
> 
> This was my thinking however I could not read this clearly in the text
> as the record protection for handshake was stated as NULL NULL AEAD.
> 
> I am still looking for clear text in {{key-calculation}} that describes
> that a strong authenticator of all sent handshake messages are returned
> to each end signed in the Finished message.

The first message keying includes hashes of all previous messages, so
those have to match for the keys to match.

For messages after the first keying, those are protected by the MAC built
into AEAD cipher.

> Anyway it offers no protection against the yellow patch cable to the
> grey box. There are many CA certs in the vendor trust stores. If you
> sent 3 certs from CAs with no relationships then you could eliminate
> this kind of tampering. multi-rooted. Verify is only a cost for 24H
> (given session caching and ticket timeout is sorted).

Yeah, certificates are another kettle of fish (made lots worse by
actual implementations that just plain don't work).

> > - TLS 1.0-1.2 w/o false start: The Finished values will fail to verify.
> > - TLS 1.0-1.2 /w false start: The selected crypto must be strong, or
> >   endpoints won't enage in false start.
> 
> OK In TLS 1.2 the spec states there is no record protection for
> handshake messages. I see verify_data field in Finished. It is vaguely
> specified in RFC5426 and RFC5288 (AES-GCM) makes no reference to it.

RFC5246 (TLS 1.2) you mean? And it does specify how Finished is computed,
and yes, it does include a hash of handshake messages in the computations.

Of course, if endpoint does not check the Finished message, things go
badly wrong (TLS 1.3 just blows up due to mismatched keys).

> However I am still skeptical as there is no record protection for
> handshake messages so I don't know what is preventing the proxy from
> returning illegal_parameter to the client hello until the client does a
> TLS1.0 ClientHello and then edit the cipher list remove SCSV and cause
> client to negotiate TLS_WITH_RSA_RC4_128_SHA with Windows XP.

Not having client ever fall back (of course, browsers have historically
been pretty bad at this, which made POODLE more than just a curiosity).

> I'm trying to find where the 12 octect verify_data is specified. If
> *all* of the the handshake payload is in a MAC in verify data then you
> could generate still generated ignored extensions to get a 96-bit hash
> collision. Still reasoning about it...

It is specified in base TLS spec (Section 7.4.9 for TLS1.2 / RFC5246).

And given the realtime requirements, even ~2^48 work to collide a 96-
bit hash is a lot of work. And looks like one would need a preimage
to do anything interesting, which is ~2^96 work (regarded infeasible
even with lots of resource).


-Ilari