Advanced SSL Topics - Implementing SSL/TLS Using Cryptography and PKI - page 453

{
perror( “Unable to receive server hello” );
return 2;
}
}
// Certificate precedes key exchange
if ( parameters->got_certificate_request )
{
send_certificate( connection, parameters );
}
The send_certificate routine is exactly the same as the one from Listing 7-11;
there's no difference between the two at all.
NOTE Because the certifi cate name is hardcoded into this routine, if you
run the server from Chapter 7 from the same directory as you run the client,
you actually return the same certifi cate that the server uses for key exchange!
Obviously, this isn't the way things normally work, but it's good enough for
illustration purposes.
Supporting the Certifi cate Verify Message
The code presented in Listing 8-30 won't quite work, though. Consider; the
client has presented a certifi cate whose common name is, for example, “Joshua
Davies.” The certifi cate is signed by a trusted CA. It's also passed in the clear, so
any eavesdropper who's listening in can capture it and reuse it, masquerading
as this “Joshua Davies” fellow. Recall that the server's certifi cate was tied to a
domain name; the client could verify that the CN component of the certifi cate's
subject name matches the domain name to which it is connecting. The server
can't do that with the client's certifi cate; the client is likely to be mobile and
probably won't have a domain name.
Therefore, there's one last thing the client needs to do in order to satisfy a
certifi cate request. It must use the private key that corresponds to the server's
public key to sign a secure hash of the handshake messages that have been
exchanged so far.
This should sound familiar; it's the same thing that was done for the fin-
ished message in Listing 6-53. In fact, the code to build the CertificateVerify
handshake message is pretty similar to the code to compute the verify data in
the fi nished message. The only real difference is that instead of iterating the
secure hash through the PRF, the secure hash is signed using the private key.
Refactoring rsa_encrypt to Support Signing
Recall from Chapter 4 that RSA signatures are data encrypted using an RSA
private key. This is almost exactly the same as RSA encryption, except that the