DUnderstanding the Pitfalls of SSLv2 - Implementing SSL/TLS Using Cryptography and PKI - page 584

#define SSL_CT_X509_CERTIFICATE 1
#define SSL_MT_ERROR 0
#define SSL_MT_CLIENT_HELLO 1
#define SSL_MT_CLIENT_MASTER_KEY 2
#define SSL_MT_CLIENT_FINISHED 3
#define SSL_MT_SERVER_HELLO 4
#define SSL_MT_SERVER_VERIFY 5
#define SSL_MT_SERVER_FINISHED 6
Because RC2 or IDEA weren't examined, they won't be supported here, although
it should be fairly straightforward at this point how you might go about doing
so. Notice that in all cases, the MAC algorithm is MD5; SHA is not supported
in SSLv2. RC4 is supported, of course, and two other bulk cipher algorithms,
DES and 3DES (identifi ed here as DES_192_EDE3) are defi ned. In all cases, block
ciphers use CBC chaining.
Also notice SSL_CK_RC4_128_EXPORT40_WITH_MD5 . SSLv2 supports export-grade
ciphers as discussed in Chapter 8, but it does so slightly differently than TLS
does. The 128 in the cipher suite identifi er, of course, identifi es the key length in
bits. However, export40 mandates that only 40 bits of the key be protected by
the key exchange algorithm; the remaining 88 bits are transmitted in the clear.
Add support for three of these ciphers in Listing C-7.
Listing C-7: “ssl.c” cipher spec declarations
#define NUM_CIPHER_SPECS 3
static CipherSpec specs[] =
{
{ SSL_CK_DES_64_CBC_WITH_MD5, 8, 8, 8, MD5_BYTE_SIZE, des_encrypt,
des_decrypt, new_md5_digest },
{ SSL_CK_DES_192_EDE3_CBC_WITH_MD5, 8, 8, 24, MD5_BYTE_SIZE,
des3_encrypt, des3_decrypt, new_md5_digest },
{ SSL_CK_RC4_128_WITH_MD5, 0, 0, 16, MD5_BYTE_SIZE, rc4_128_encrypt,
rc4_128_decrypt, new_md5_digest }
};
So how does the SSL handshake work? First, the client advertises to the
server which cipher specs it supports; it's not required to support all of them.
The server responds by advising the client which specs it supports, as well as
sending an X.509 certifi cate containing its public RSA key. Assuming there's at
least one cipher spec that both sides understand, the client selects one, creates
a key, encrypts it using the server's public key, and sends it on. This exchange
is illustrated in Figure C-1.
As a double-check against man-in-the-middle attacks, the client also sends
a challenge token, which the server must encrypt using the newly negotiated
key before sending back the encrypted value, in its hello message. The client
verifi es that the decrypted token is the same as what was sent. If it's not, the