The Triple Handshake Issue was disclosed lately. As far as I understand it, it highly depends on renegotiation and resumption.

So the simple question is: Would disabling resumption and/or renegotiation mitigate this problem?

In more details:

Renegotiation seems to be quite secure, and there is only one problem about new certificates being presented. The authors highly recommend checking the newly presented certificate carefully. So fixing this would allow to keep renegotiation.

Resumption seems to be quite insecure. So until a long term fix is deployed, it seems to be better to disable it completely. Is this correct?

I am aware that disabling resumption will have a performance impact. For my current scenarios this is not relevant (long living TLS sessions). If someone still wants to elaborate on details, don't hesitate.

2 Answers 2


If there is no resumption, it is clear that this attack can't exist, however, resumption is a very important and attractive function of TLS since it can reduce latency effectively. So,TLS 1.3 may not support renegotiation rather than resumption any more.


From my understanding the main point of the attack is, that the part of the browser responsible for checking the Same Origin Policy thinks it is connected to host A, while the part responsible for sending the appropriate client certificate thinks it is connected to host B because it got the certificate for this host in the renegotiation. This way the browser will let script etc from host A access authorized data from host B, because it thinks they are from A.

If you disable renegotiation this attack should not work any longer, even if session resumption is still enabled. But, if you really need renegotiation you should disable session resumption so that the attack does not work.

  • 1
    As far as I understand it: There are two main points: 1. Resumption works and ends with the exact same tls-unique thing. This should not happen. 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." so resumption is broken somehow. 2. After (1) tls-unique is the same and allows A to replay the renegotiation. So disabling resumption (which seems quite broken now) would stop this attack quite early.
    – Elrond
    Commented Mar 13, 2014 at 22:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .