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.
