![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
David-Sarah Hopwood wrote: > Michael D'Errico wrote: >>> Suppose that the client sent an SSLv3 ClientHello >>> with client_version = 3.1 (or higher). Assuming the server supports TLS, >>> then TLS will be negotiated. So when the client sends the renegotiation, >>> it knows that it is safe to send extensions. The attack is prevented as >>> long as the renegotiating handshake uses the extension; it is not >>> necessary for the initial handshake to have used it. >> The problem is that your initial handshake *is* the renegotiation! >> (from the server's point of view) > > I may well be confused, but: a handshake is a renegotiation if-and-only-if > it is encrypted. Initial handshakes are in the clear. So there is no > ambiguity, from either party's point of view, about whether a handshake > is a renegotiation. Actually this is not quite right, although not in a way that affects my main point. A handshake is a renegotiation from the server's point of view if-and-only-if a ciphersuite other than TLS_NULL_WITH_NULL_NULL is in effect. It is possible that an initial handshake by a client that was sent in the clear, could be encrypted by an attacker and appear to the server as a renegotiation. In that case, the server can reject the renegotiation if the ClientHello doesn't contain a correct (and non-empty) Renegotiation_Info. It is also possible that, if a client that does not support the extension requests a renegotiation on a session with the attacker, then the attacker can decrypt it and present it to the server as an initial handshake. But this only applies to clients that do not support the extension at all. If a client does support it and sends it only when renegotiating, then this variant of the attack is still prevented. So, I was right in my original statement that "the attack is prevented as long as the renegotiating handshake uses the extension." Note that both clients and servers must avoid renegotiating without using the extension; it isn't sufficient for only servers to avoid doing so. As long as that is the case, for a client does support the extension, failing to send the zero-length Renegotiation_Info in an initial handshake does not enable an attack. -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
Attachment:
signature.asc
Description: OpenPGP digital signature