1

Triple handshake attack was discovered lately, and to quote the article "The secure renegotiation indication extension only binds handshakes on the same connection, but does not apply if the session is resumed on a new connection.", that is to say, after an initial handshake in one connection, the old session is resumed in a new connection and then the resumed session would be renegotiated in the same connection.

However, if the resumed session is in the same connection as the original session, can this attack still exist? Intuitively, it still exists, since the renegotiation will only check the finished message of the just closed session which is the resumed session rather than the original session. Is it right?

xinyu
  • 52
  • 6

1 Answers1

0

The Finished value checked by Secure Renegotiation is for the previous handshake on the same connection as seen by each party, but the attacker had to tamper with the initial (full) handshake, so the check values differ. Look at the items in red in their figure; those cause log1 and log1' (prime) to differ, similarly log2 and log2'.

Community
  • 1
dave_thompson_085
  • 9,759
  • 1
  • 24
  • 28
  • But, as the the "Transport Layer Security (TLS) Renegotiation Indication Extension" says, renegotiation will only check the finished message in the enclosing resumed session rather than the original session. So, I don't know whether this attack may still exist if all these three handshakes are in the same connection. Hope to discuss this with you! – xinyu Jun 10 '15 at 00:59
  • @xinyu What makes you think the resumed session is 'enclosing'? It isn't and in general can't be. The introduction is a little vague but 3.2 says 'enclosing TLS connection if any' and then details that RI uses the Finished values from the previous handshake if there was one *on the connection* otherwise (at initial handshake) empty. Renegotiation can be either a new session or a resumed session (if available) and initial handshake/negotiation can also be either a new session or a resumed one (if available). ... – dave_thompson_085 Jun 11 '15 at 06:56
  • ... The second handshake in the attack works precisely because RI is empty for an initial handshake, even though it can be and in this case is a resumed session. If you tried to do the second handshake on the same (first) connection it wouldn't work, as their figure clearly shows, hence my answer. – dave_thompson_085 Jun 11 '15 at 06:57
  • I just have not found the evidence that renegotiation can be either a new session or a resumed session. What I have seen is that renegotiation is a process by which the full handshake process takes place over an already existing TLS connection, so why did you say a resumed session can also be called renegotiation? – xinyu Jun 11 '15 at 08:44
  • @xinyu (sorry for delay) I don't think you'll find a spec statement. The handshake protocol has two options, full or abbreviated. Handshake can be initiated at the beginning of a connection (initial), or after a previous handshake/session is already in effect (renegotiation). There are four combinations, and all are permitted unless something restricts them, and nothing does. See my answer to your other question http://security.stackexchange.com/questions/91248/questions-about-triple-handshakes-considered-harmful-breaking-and-fixing-authen which covers this in detail. – dave_thompson_085 Jun 18 '15 at 09:14
  • I still have another related question: In one connection, assume that the initial handshake is a full handshake, and we know from https://eprint.iacr.org/2012/630.pdf that the renegotiation messages are transmitted within the existing record layer to protect the privacy of the client's certificate, however, does this mean that all the following renegotiation(abbreviated or full handshake) should be processed under the secure channel established by the first handshake? If "Yes", why? – xinyu Jun 19 '15 at 14:01
  • @xinyu Renegotiation messages use the *current* security parameters (which are from the initial handshake if this is the first renegotiation, but the previous renegotiation if this is a second or more renegotiation) up to the ChangeCipherSpec message, at which point the parameters chosen by this renegotiation take effect. This does have the _effect_ of hiding the client cert if (real) client auth is done only on renegotiation(s) and not initially, but I've never seen anything to indicate if that is the _reason_ the designers chose to do it this way. ... – dave_thompson_085 Jun 21 '15 at 01:05
  • ... If your question is "why" must implementations do what the spec says, the reason is the same as all communications protocols: if both ends don't implement the same protocol, they can't successfully communicate, and the purpose of using communication protocols is to communicate. – dave_thompson_085 Jun 21 '15 at 01:07
  • From the TLS standard, I have not found the accurate definition of the term of "renegotiation", so how do we implement TLS renegotiation if TLS does't describe it in detail? – xinyu Jun 21 '15 at 02:19