The previous section explained how a server can send a Certificate message instead of a ServerKeyExchange message to authenticate it- self. One consequence of this approach is that the same public key information used to verify the server’s identity is also used to encrypt key material in the client’s ClientKeyExchange message. This con- straint is not always desirable; indeed, in some cases it is actually im- possible to support.
The impossible cases are easiest to describe. Some public key algo- rithms (such as the Digital Signature Algorithm) can only be used for signing. By their very design, they cannot be used for encryption. In such cases, it will be impossible for the client to encrypt its Cli- entKeyExchange information using the server’s public key.
This limitation alone would be sufficient to require greater flexibility from the ssl protocol, but it is worthwhile to understand why com- bining signing and encryption might be undesirable, even when the public key algorithm supports both operations. The most common reason for separating encryption from signing is based not on techni- cal considerations, but on legal ones. Some countries, including im- portant producers of cryptographic products such as the United States (at least at the time of this writing), control the use or the ex- port of products that include cryptography. In particular, the United States makes it more difficult for suppliers to export cryptographic products that use encryption key lengths greater than a certain minimum. (Key lengths less than or equal to these limits are said to
Server ClientHello ServerHello Certificate ServerHelloDone ClientKeyExchange ChangeCipherSpec Finished ChangeCipherSpec Finished 1 2 3 5 6 7 8 9 10 ServerKeyExchange 4 Client
be exportable.) In principle, at least, the United States does not im- pose the same restrictions on keys used for digital signatures. Systems that fall under u.s. jurisdiction, therefore, may prefer to use the long- est practical keys for authenticating their identity (thus providing the strongest practical authentication), but use encryption keys that con- form to the weaker export restrictions.
Whatever the reason, ssl does provide a mechanism for separating server authentication from the encryption. Table 3-9 outlines the steps involved, and figure 3-6 illustrates the entire process. The figure highlights the three messages that are significant for separating en- cryption and server authentication. They are the Certificate, ServerKeyExchange, and ClientKeyExchange messages.
Table 3-9 Separating Server Authentication from Encryption Step Action
1 Client sends ClientHello message proposing SSL options. 2 Server responds with ServerHello message selecting the SSL
options.
3 Server sends its public key certificate in Certificate message. 4 Server sends the public key that the client should use to en-
crypt the symmetric key information in a ServerKeyExchange; this public key is signed with the public key in the server’s cer- tificate.
5 Server concludes its part of the negotiation with ServerHello- Done message.
6 Client sends session key information (encrypted with the public key provided by the server) in a ClientKeyExchange message. 7 Client sends ChangeCipherSpec message to activate the nego-
tiated options for all future messages it will send.
8 Client sends Finished message to let the server check the newly activated options.
9 Server sends ChangeCipherSpec message to activate the nego- tiated options for all future messages it will send.
10 Server sends Finished message to let the client check the newly activated options.
3.6.1 Certificate
The Certificate message in this example is identical to the example in section 3.5, except that the public key in the server’s certificate will only be used to verify its identity. The client still has all the responsi- bilities section 3.5.1 discussed, however. It must verify the certificate’s signatures, validity times, and revocation status, and it must ensure that the certificate authority is trusted, and that the certificate was is- sued to the party with whom it wishes to communicate.
3.6.2 ServerKeyExchange
The server follows its Certificate message with a ServerKeyExchange message. It is this second message that contains the public key the client should use to encrypt session key information. The ServerKeyExchange is the same message that we saw when no au- thentication was involved, and the information contained in the mes- sage is the same as described in section 3.3.3—with one significant difference: Unlike the example of section 3.3, in which the server keys were sent by themselves, in this scenario, the key information is signed using the public key contained in the server’s certificate. This step is essential to give the client a way to verify that the server really does possess the private key corresponding to its public key certifi- cate.
3.6.3 ClientKeyExchange
The client uses a ClientKeyExchange message to finish the negotia- tion process, just as it does in other scenarios. As before, this message contains the key information for the symmetric encryption algorithm the two parties have selected. Also as before, this information is en- crypted using the server’s public key. It is important to note that the public key used for this encryption is the public key from the ServerKeyExchange message, not the public key from the server’s Certificate message (even if that public key algorithm supports en- cryption).