Cryptography Reference
In-Depth Information
After you verify the certifi cate and decide to trust this connection, the man in
the middle takes over, drops the connection to the server, and you complete the
handshake with the falsifi ed server, none the wiser.
Therefore, the specifi cation enables the server key exchange to be signed by
the public key in the certifi cate. This optional signature immediately follows the
key exchange parameters if present; it is present for any key exchange except
for the anonymous types.
Extend the parse_server_key_exchange function from Listing 8-19 as shown
in Listing 8-20 to recognize this signature if it is present and verify it. If it is
present but doesn't verify according to the previously received certifi cate, return
NULL, which causes the calling tls_receive_message to fail with the illegal
parameter handshake alert.
Listing 8-20: “tls.c” parse_server_key_exchange with signature verifi cation
static char *parse_server_key_exchange( unsigned char *read_pos,
TLSParameters *parameters )
{
for ( i = 0; i < 4 ; i++ )
case 3:
// The third element is the signature over the first three, including their
// length bytes
if ( !verify_signature( dh_params,
( read_pos - 2 - dh_params ),
read_pos, length, parameters ) )
{
return NULL;
}
break;
}
The signature type depends on the type of public key in the certifi cate. TLS
defi nes two: RSA and DSA. Recall from Chapter 3 that an RSA signature is
a secure hash of the data to be signed, encrypted with the private key. TLS
actually takes a slightly more paranoid approach to RSA signatures, and
encrypts both the MD5 and the SHA-1 hash, presumably to guard against
a compromise of either hash function. Unfortunately, both are fairly weak
today, and TLS 1.0 doesn't provide a way to negotiate a stronger hash function.
Recall from Chapter 5 that the X.509 certifi cate signature included the OID
of the corresponding hash function in its signature; TLS 1.0, unfortunately,
didn't follow suit.
 
Search WWH ::




Custom Search