Cryptography Reference
In-Depth Information
while ( !parameters->server_hello_done )
{
if ( receive_tls_msg( connection, NULL, 0, parameters ) < 0 )
while ( !parameters->server_finished )
{
if ( receive_tls_msg( connection, NULL, 0, parameters ) < 0 )
...
This change is just necessary to satisfy the compiler; at no point does receive_
tls_msg actually check this pointer for NULL. If a handshake message is expected
and application data arrives, you get an unhelpful segmentation violation.
There's still a problem here. If you glance back at the implementation of
display_result in Listing 6-3, you notice that it calls for a buffer of data at a
time — in this case, 255 bytes. However, there's no guarantee that this much
data is available in the next TLS packet, nor is there a guarantee that there isn't
more. Therefore, whenever the application calls tls_recv with a buffer set to
receive a chunk of application data, the routine must check to see if there's any
left over from a previous call, as well as store any that was decrypted but that
the user didn't ask for.
To accommodate variable-length input, follow these steps:
1. Add a buffer to the end of the TLSParameters structure as shown in
Listing 6-73.
Listing 6-73: “tls.h” TLSParameters with buffering support
typedef struct
{
char *unread_buffer;
int unread_length;
}
TLSParameters;
2. receive_tls_msg must also be updated to check this buffer for any unread
bytes whenever the application asks for more data, as well as to buffer any
data that was decrypted but that the user didn't ask for. This is shown in
Listing 6-74.
Listing 6-74: “tls.c” receive_tls_msg with buffering support
void init_parameters( TLSParameters *parameters,
int renegotiate )
{
parameters->server_hello_done = 0;
parameters->server_finished = 0;
Search WWH ::




Custom Search