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

do this, and pass the premaster secret into rsa_key_exchange . However, this
confi guration makes DH key exchange easier to support because the upcom-
ing dh_key_exchange necessarily has to select the premaster secret, due to the
nature of the Diffi e-Hellman algorithm.
The rsa_key_exchange message is built in Listing 6-38.
Listing 6-38: “tls.c” rsa_key_exchange
int rsa_key_exchange( rsa_key *public_key,
unsigned char *premaster_secret,
unsigned char **key_exchange_message )
{
int i;
unsigned char *encrypted_premaster_secret = NULL;
int encrypted_length;
// first two bytes are protocol version
premaster_secret[ 0 ] = TLS_VERSION_MAJOR;
premaster_secret[ 1 ] = TLS_VERSION_MINOR;
for ( i = 2; i < MASTER_SECRET_LENGTH; i++ )
{
// XXX SHOULD BE RANDOM!
premaster_secret[ i ] = i;
}
encrypted_length = rsa_encrypt( premaster_secret, MASTER_SECRET_LENGTH,
&encrypted_premaster_secret, public_key );
*key_exchange_message = ( unsigned char * ) malloc( encrypted_length + 2 );
(*key_exchange_message)[ 0 ] = 0;
(*key_exchange_message)[ 1 ] = encrypted_length;
memcpy( (*key_exchange_message) + 2, encrypted_premaster_secret,
encrypted_length );
free( encrypted_premaster_secret );
return encrypted_length + 2;
}
This function takes as input the RSA public key, generates a “random” pre-
master secret, encrypts it, and returns both the premaster secret and the key
exchange message. The format of the key exchange message is straightforward;
it's just a two-byte length followed by the PKCS #1 padded, RSA encrypted
premaster secret. Notice that the specifi cation mandates that the fi rst two bytes
of the premaster secret must be the TLS version — in this case, 3.1. In theory,
the server is supposed to verify this. In practice, few servers do the verifi cation
because there are a few buggy TLS implementations fl oating around that they
want to remain compatible with.