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