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?

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'.

  • 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 0: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 6: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 6: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 8: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 security.stackexchange.com/questions/91248/… which covers this in detail. – dave_thompson_085 Jun 18 '15 at 9:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.