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

int response;
record.msg_type = msg_type;
record.length = htons( message_len ) << 8; // To deal with 24-bits...
send_buffer_size = message_len + 4; // space for the handshake header
send_buffer = ( unsigned char * ) malloc( send_buffer_size );
send_buffer[ 0 ] = record.msg_type;
memcpy( send_buffer + 1, &record.length, 3 );
memcpy( send_buffer + 4, message, message_len );
response = send_message( connection, content_handshake,
send_buffer, send_buffer_size );
free( send_buffer );
return response;
}
This would be a bit simpler except that, for some strange reason, the TLS
designers mandated that the length of the handshake message must be given
in a 24-bit fi eld, which no compiler that I'm aware of can generate. Of course,
on a big-endian machine, this wouldn't be a problem; just truncate the high-
order byte of a 32-bit integer and you'd have a 24-bit integer. Unfortunately,
most general purpose computers these days are little-endian, so it's necessary
to convert it and then truncate it.
But send_handshake_message still doesn't call send! TLS mandates not only
that every handshake message be prepended with a header indicating its type
and length, but that every message, including the already-prepended handshake
messages, be prepended with yet another header indicating its type and length!
So, fi nally, defi ne yet another header structure and some supporting enu-
merations in Listing 6-16.
Listing 6-16: “tls.h” TLSPlaintext header
/** This lists the type of higher-level TLS protocols that are defined */
typedef enum {
content_change_cipher_spec = 20,
content_alert = 21,
content_handshake = 22,
content_application_data = 23
}
ContentType;
typedef enum { warning = 1, fatal = 2 } AlertLevel;
/**
* Enumerate all of the error conditions specified by TLS.
(Continued)