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

memcpy( &parameters->active_recv_parameters,
&parameters->pending_recv_parameters,
sizeof( ProtectionParameters ) );
…

Note that the sequence number is never transmitted, encrypted or otherwise;
it's just prepended to the MAC buffer before the packet is MAC'ed. Therefore,
given a content buffer of “content”, the buffer that is MAC'ed looks like this:

MESSAGE
TYPE

SEQUENCE NUM VERSION CONTENT LENGTH CONTENT

4 bytes 1 byte 2 bytes 2 bytes variable

A digest is produced over this data.
What's actually transmitted, on the other hand, is

CONTENT LEN +
MAC LEN +
PADDING LEN

MESSAGE
TYPE

VERSION CONTENT MAC

1 byte 2 bytes 2 bytes variable variable

But this is, of course, encrypted before sending. Notice that the buffer is
MAC'ed fi rst and then encrypted. The order is clearly important so that the
other side can correctly receive it.

Supporting Outgoing Encryption

To support encryption — outgoing — the only function that needs to be updated
is the send_message function. In order to apply the active cipher suite, it needs to
be sent the active ProtectionParameters so that it can check to see what cipher
suite is active, and apply that cipher suite. Remember that TLS_NULL_WITH_NULL_
NULL is a valid cipher suite, and it's the one that's active when the handshake fi rst
starts. It just tells send_message to do no MAC nor encrypt. In this way, there's
always a cipher suite active, even if it's a “do nothing” cipher suite.
The fi rst thing send_message must do is to create the MAC buffer and compute
the MAC. To do this, follow these steps:

1. Check for an active digest and apply it to the contents as shown in
Listing 6-61.

Listing 6-61: “tls.c” send_message with MAC support

static int send_message( int connection,
int content_type,
const unsigned char *content,
short content_len,

(Continued)