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