Advanced SSL Topics - Implementing SSL/TLS Using Cryptography and PKI - page 435

}
}
else
{
if ( send_server_hello( connection, parameters ) )
If the session isn't being resumed — that is, it's new — the tls_accept must
also remember it for future resumptions as shown in Listing 8-16.
Listing 8-16: “tls.c” tls_accept with session storage
if ( !( send_finished( connection, parameters ) ) )
{
perror( “Unable to send client finished” );
send_alert_message( connection, handshake_failure,
&parameters->active_send_parameters );
return 7;
}
// Handshake is complete; now ready to start sending encrypted data
// IFF the handshake was successful, put it into the sesion ID cache
// list for reuse.
remember_session( parameters );
}
The only other change that needs to made here is that init_parameters must
initialize the session ID to be empty, as in Listing 8-17.
Listing 8-17: “tls.c” init_parameters with session resumption support
static void init_parameters( TLSParameters *parameters )
{
…
parameters->session_id_length = 0;
}
Drawbacks of This Implementation
This implementation is by no means perfect, or complete. After a session is
added to the hash table, it's never removed until the server shuts down. Not
only is this an operational problem — its memory consumption grows without
bounds until it crashes — it's also a security problem because a session can be
resumed days or even weeks afterward. This won't be a signifi cant problem
for the use you put this server to, but it would be for a highly available server.
The TLS specifi cation, RFC 2246, mandates that if a session was not shut down
correctly — if the client didn't send a close notify alert before shutting down the
socket — then the session should be marked non-resumable and attempts to resume
it should fail. From section 7.2.1 of the RFC, which discusses the close_notify alert: