Subject: Re: [TLS] TLS Digest, Vol 65, Issue 76

From: Ravi Ganesan <[email-masked]>
Date: Thu, 17 Dec 2009 22:49:58 -0800

> I do agree with you there.  Unless the saved session mechanism also
> triggers the functionality and checks that a full handshake would, but
> I think that's too much to hope for.
>
> -Kyle H

I know everyone on this thread knows otherwise, but the way the terms get
used, can easily result in confusion between "full handshake", "abbreviated
handshake" and "renegotiated full handshake".  The attack only applies of
course to last category, and NOT to the abbreviated handshake.

To be pedantic, in the "full" handshake the two sides (or at least the
Server) prove identity to each other using their private keys and
certificates chaining to mutually trusted roots, and exchange the
"master_secret" which is really the "session key". This "master_secret" can
be used by the "abbreviated handshake" to create many (including parallel)
subsequent sessions with each party proving identity here by proving
possession of the session key (the "master secret"). During the abbreviated
handshake one simply CANNOT do all the checks in the full handshake, not
because the developer chose not to do it, but because there is no question
of public key credentials...the abbreviated handshake is relying purely on
the shared secret (via the server.verify and client.verify).

Sorry if this is so obvious to those on this thread, but a lot about SSL is
*not* obvious to the world at general, and unfortunately a number of people
are convinced that the attack discovered a flaw in session resumption or
opening parallel sessions using the abbreviated handshake. If it did, I
missed it perhaps.  If not, perhaps language in text clarifying this
'obvious' point might be useful.

Thanks,

Ravi
-- 
Ravi Ganesan
[email-masked]
www.findravi.com

---

From: Marsh Ray <[email-masked]>
Date: Fri, 18 Dec 2009 01:25:14 -0600

Ravi Ganesan wrote:
> 
> I know everyone on this thread knows otherwise, but the way the terms
> get used, can easily result in confusion between "full handshake",
> "abbreviated handshake" and "renegotiated full handshake".

It took me a long time to stop getting mixed up between "renegotiation"
and "resumption". There was some discussion about this, but it turns out
they are completely orthogonal.

> The attack
> only applies of course to last category, and NOT to the abbreviated
> handshake.

No, it applies equally to session resumption "abbreviated" handshakes.

They can also be conducted during a renegotiation. OpenSSL even defines
an option SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION. I'm sure
there's a story behind that one.

> [...]
> 
> Sorry if this is so obvious to those on this thread, but a lot about SSL
> is *not* obvious to the world at general, and unfortunately a number of
> people are convinced that the attack discovered a flaw in session
> resumption or opening parallel sessions using the abbreviated handshake.
> If it did, I missed it perhaps.  If not, perhaps language in text
> clarifying this 'obvious' point might be useful.

draft-ietf-tls-renegotiation-02 contains the text:

> The above rules apply even when TLS session resumption is used.

and

>    TLS clients which support this specification MUST generate either the
>    "renegotiation_info" extension or the TLS_RENEGO_PROTECTION_REQUEST
>    SCSV with every ClientHello, including ClientHellos where session
>    resumption is being offered.

The RI extension should fix renegotiation regardless of whether a new
session is being established or a previous session is being resumed.

- Marsh

---

From: Ravi Ganesan <[email-masked]>
Date: Thu, 17 Dec 2009 23:55:24 -0800

> there's a story behind that one.
Marsh, I re-read the relevant links and it did not jump out on me. Am sure I
am missing something but can you elaborate on how this happens? i.e. the
genuine Client and geniune Server have agreed on a master secret using their
respective certs, and are trying to establish a new session using the
abbreviated handshake, using the session_key (the master_secret, which
hopefully in TLS 1.x will be renamed the session_key!). How does MITM
intervene? Thx.

-- 
Ravi Ganesan
[email-masked]
www.findravi.com

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sat, 19 Dec 2009 03:53:50 +0000

> course to last category, and NOT to the abbreviated handshake.

Well, it also applies to a renegotiated abbreviated handshake (where a
renegotiating handshake resumes an existing session). The spec should
probably point out that this case is possible, and that exactly the same
attacks and defences apply.

> the shared secret (via the server.verify and client.verify).

It's relying on the fact that those checks were done correctly in the
session that is being resumed.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com