1

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.

SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
Elrond
  • 145
  • 1
  • 5

2 Answers2

1

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.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • 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 Mar 13 '14 at 22:08
1

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.

xinyu
  • 52
  • 6