Adding TLS 1.2 Support to Your TLS Library - Implementing SSL/TLS Using Cryptography and PKI - page 485

Impact to Diffi e-Hellman Key Exchange
As mentioned previously, the changes in the previous section are suffi cient to
support TLS 1.2 in the most straightforward case: when RSA is used directly
for key exchange. However, there's one other signifi cant structural change that
was introduced by TLS 1.2 that impacts ephemeral Diffi e-Hellman (DHE) key
exchange suites. Recall that when DHE is used for key exchange the server
must sign the DH parameters g , p , and Ys with the private key corresponding to
the public key in the server's certifi cate. Prior to TLS 1.2, the type of signature
was implied. If the server certifi cate included an RSA key, the client knew that
the signature was an RSA signature. If the certifi cate was a DSA key, the client
knew to perform a DSA signature check.
This works, but in the long-term is a bit of a burden on the implementer. It
would be nice if each signature included an indicator of what type it is; this is
exactly what TLS 1.2 added to the inline signatures. Additionally, recall from
Listing 8-21 that RSA signatures were RSA-encrypted concatenations of the
MD5 hash followed by the SHA-1 hash. TLS 1.2 changes this here, just as it
does in the PRF; an RSA signature is an encrypted representation of a single
hash — SHA-256 unless a client hello extension has negotiated a different hash.
The hash algorithm is also identifi ed in the encrypted data, just like an X.509
signature is. This is redundant; the signature fi rst declares the hash algorithm,
and then the signature itself redeclares it. Why was it done this way? DSA has
no provision for including a declaration of a hash algorithm, so TLS 1.2 adds it
before the signature as well.
Parsing Signature Types
To parse these new signature types, modify the verify_signature code from
Listing 8-21 as shown in Listing 9-8 to fi rst read off the hash and signature
algorithm and then to ASN.1-decode the decrypted RSA signature value to
locate the actual signed hash code. (DSS validation stays the same, as it must.)
Listing 9-8: “tls.c” TLS 1.2 signature verifi cation
int verify_signature( unsigned char *message,
int message_len,
unsigned char *signature,
int signature_len,
TLSParameters *parameters )
{
…
digest_ctx sha_digest;
new_sha256_digest( &sha_digest );
(Continued)