A Usable, Secure Communications Protocol: Client-Side TLS - Implementing SSL/TLS Using Cryptography and PKI - page 346

else
{
memcpy( &parameters->active_recv_parameters,
&parameters->pending_recv_parameters,
sizeof( ProtectionParameters ) );
init_protection_parameters( &parameters->pending_recv_parameters );
}
}
}
Now, when the server sends its change_cipher_spec message, the pend-
ing receive parameters are updated and made the active receive parameters.
Technically, the change cipher spec messages can “cross” on the wire. The
server may legally send its change cipher spec message as soon as it receives
a proper key exchange from the client; it doesn't strictly have to wait until the
client sends a change cipher spec.
TLS Finished
So, the key exchange has been completed, both sides have agreed that the pend-
ing parameters are now the active parameters. It's time to start using the con-
nection, right?
Well, that's what the designers of SSLv2 thought, too. As it turns out, this was
the fatal fl aw in SSLv2. After the key exchange had completed, the connection
was used immediately to transfer data. The problem with this is that it doesn't
take into account man-in-the-middle attacks that occur before the key exchange.
Although the key exchange protocol designed around X.509 certifi cates does
an admirable job of protecting against man-in-the-middle attacks against the
public key, the malicious man in the middle can intercept and modify all the
exchanges prior to this.
How can an attacker use this to his advantage? Well, he could, for instance,
change the client hello message to list only one possibility for a cipher suite — DES
with MD5 MAC. If he has a DES-cracking machine, the key exchange can pro-
ceed, and he can decode the communications at his leisure.
In general, both sides need a way to strongly authenticate that what they
sent was what was received. The way TLS accomplishes this is to require
both sides to send a fi nished message before the handshake can be considered
complete. Both of these fi nished messages must be sent before the negoti-
ated parameters can be used for application data, and the fi nished messages
themselves are sent using the negotiated encryption and authentication
parameters. The contents of this fi nished message are a 12-byte verify array
whose contents are based on the hash of the contents of all of the handshake
messages to this point.