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

#define MASTER_SECRET_LENGTH 48
typedef unsigned char master_secret_type[ MASTER_SECRET_LENGTH ];
#define RANDOM_LENGTH 32
typedef unsigned char random_type[ RANDOM_LENGTH ];
typedef struct
{
master_secret_type master_secret;
random_type client_random;
random_type server_random;
ProtectionParameters pending_send_parameters;
ProtectionParameters pending_recv_parameters;
ProtectionParameters active_send_parameters;
ProtectionParameters active_recv_parameters;
// RSA public key, if supplied
public_key_info server_public_key;
// DH public key, if supplied (either in a certificate or ephemerally)
// Note that a server can legitimately have an RSA key for signing and
// a DH key for key exchange (e.g. DHE_RSA)
dh_key server_dh_key;
...
}
TLSParameters;
TLS 1.0 is SSL version 3.1, as described previously. The pending_send_parameter
and pending_recv_parameters are the keys currently being exchanged; the TLS
handshake fi lls these out along the way, based on the computed master secret.
The master secret, server random, and client random values are likewise pro-
vided by various hello and key exchange messages; the public keys' purpose
ought to be clear to you by now.
What about this active_send_parameters and active_recv_parameters ?
After the TLS handshake is complete, the pending parameters become the
active parameters, and when the active parameters are non-null, the param-
eters are used to protect the channel. Separating them this way simplifi es
the code; you could get away with a single set of send and recv parameters in the
TLSParameters structure, but you'd have to keep track of a lot more state in
the handshake code.
Both the TLSParameters and ProtectionParameters structures are shown
partially fi lled out in Listings 6-4 and 6-5; you add to them along the way as
you develop the client-side handshake routine.
As always, you need a couple of initialization routines, shown in
Listing 6-6.