Cryptography Reference
In-Depth Information
{
return -1;
}
free( mac_buffer );
}
return decrypted_length;
}
This is essentially the inverse of the encryption performed in
send_message . There aren't any real surprises here; the buffer is decrypted
and a MAC buffer is built and verifi ed. The MAC buffer is built the same
as it is in send_message ; if you're so inclined, you could probably refactor
this into a common routine and share it between the two. After the local
MAC has been computed, verifying it is just a matter of comparing it, byte-
for-byte, with the MAC that the server sent.
NOTE Technically, there's a security fl aw in this implementation. According
to the specifi cation, if the padding byte is x then it must be preceded by x
bytes of the byte x . This implementation doesn't explicitly verify this so a
determined attacker can attempt to take advantage of this and determine the
length of the original plaintext.
This vulnerability is highly theoretical and discussed in more detail at
http://www.openssl.org/~bodo/tls-cbc.txt ; on the other hand, it's
trivial to defend against as long as you're aware of it — just verify that the pad-
ding bytes equal the padding length.
TLS Send
That's it. The TLS handshake is complete, and tls_connect returns control back
up to the calling function, which, in this case, is the main routine of the HTTPS
utility. From this point on, nothing can be sent on this connection unless it's
encrypted, authenticated, and prepended with a correct TLS header. So, as you
recall from Listing 6-3, each call to the socket-level send function is replaced
with a call to tls_send . With the infrastructure developed in the previous sec-
tions, this is simple to implement, in Listing 6-69.
Listing 6-69: “tls.c” tls_send
int tls_send( int connection,
const char *application_data,
int length,
int options,
TLSParameters *parameters )
{
send_message( connection, content_application_data, application_data, length,
&parameters->active_send_parameters );
 
Search WWH ::




Custom Search