Cryptography Reference
In-Depth Information
network_number = htons( package.key_arg_len );
write_buffer = append_buffer( write_buffer,
( void * ) &network_number, 2 );
write_buffer = append_buffer( write_buffer, package.clear_key,
package.clear_key_len );
write_buffer = append_buffer( write_buffer, package.encrypted_key,
package.encrypted_key_len );
write_buffer = append_buffer( write_buffer, package.key_arg,
package.key_arg_len );
status = send_handshake_message( connection,
SSL_MT_CLIENT_MASTER_KEY, send_buffer, buf_len, parameters );
free( package.clear_key );
free( package.encrypted_key );
free( package.key_arg );
free( send_buffer );
return status;
}
First fi ll out a ClientMasterKey struct, fl atten it, and then send it as an SSL_
MT_CLIENT_MASTER_KEY handshake message. Notice that clear_key is always 0
(no support for export-grade ciphers), and that rsa_encrypt , from Chapter 3, is
invoked to encrypt the master key. Otherwise, this works just like the previous
two handshake messages.
SSL Client Finished
As noted above, the specifi cation makes it appear that the client should send
client_finished before expecting the next message, a server_verify . Technically
speaking, it doesn't really matter; neither of these two messages depends on
the other. In general, the server sends the server_verify immediately with-
out waiting for the client_finished , and the client sends client_finished
without waiting for server verify, so these two messages can and do “pass” each
other in transmit. Go ahead and follow the specifi cation's advice and send the
client fi nished before looking for the server verify.
ClientFinished is a pretty simple message, as shown in Listing C-22.
Listing C-22: “ssl.h” ClientFinished declaration
typedef struct
{
unsigned char *connection_id;
}
ClientFinished;
As you can see, it just refl ects the connection_id back to the server.
 
Search WWH ::




Custom Search