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

validity period of the certifi cate contains the current date. Clearly, an industrial-
strength TLS implementation needs to do at least all of these things.
TLS Server Hello Done
After the certifi cate the server should send a hello done message — at least that's
what happens in the most common type of TLS handshake being examined here.
This indicates that the server will not send any more unencrypted handshake
messages on this connection.
This may seem surprising, but if you think about it, there's nothing more
for the server to do. It has chosen a cipher suite acceptable to the client and
provided enough information — the public key — to complete a key exchange
in that cipher suite. It's incumbent on the client to now come up with a key and
exchange it. Parsing the server hello done message is trivial, as in Listing 6-30.
Listing 6-30: “tls.c” receive_tls_message with server hello done support
switch ( handshake.msg_type )
{
…
case server_hello_done:
parameters->server_hello_done = 1;
break;
As you can see, there's really nothing there; the server hello done message
is just a marker and contains no data. Note that this will almost defi nitely be
piggy-backed onto a longer message that contains the server hello and the
server certifi cate.
This routine just sets a fl ag indicating that the server hello done message has
been received. Add this fl ag to TLSParameters as shown in Listing 6-31; it's used
internally to track the state of the handshake.
Listing 6-31: “tls.h” TLSParameters with state tracking included
typedef struct
{
…
int server_hello_done;
}
TLSParameters;
Finally, recall that this whole process was being controlled by tls_connect .
It sent a client hello message and then received the server hello. Due to piggy-
backing of handshake messages, though, that call to receive probably picked up
all three expected messages and processed them, culminating in the setting of
server_hello_done . This isn't guaranteed, though; the server could legitimately
split these up into three separate messages (the server you develop in the next