Although section 3.4 explained how ssl can establish encrypted communications between two parties, that may not really add that much security to the communication. With encryption alone neither
Server ClosureAlert
ClosureAlert Client
party can really be sure of the other’s identity. The typical reason for using encryption in the first place is to keep information secret from some third party. But if that third party were able to successfully masquerade as the intended recipient of the information, then en- cryption would serve no purpose. The data would be encrypted, but the attacker would have all the data necessary to decrypt it.
To avoid this type of attack, ssl includes mechanisms that allow each party to authenticate the identity of the other. With these mecha- nisms, each party can be sure that the other is genuine, and not a masquerading attacker. In this section, we’ll look at how ssl enables a server to authenticate itself.
A natural question is, of course, if authenticating identities is so im- portant, why don’t we always authenticate both parties? The answer lies in the nature of Web commerce. When you want to purchase something using your Web browser, it’s very important that the Web site you’re browsing is authentic. You wouldn’t want to send your credit card number to some imposter posing as your favorite mer- chant. The merchant, on the other hand, has other means for authenticating your identity. Once it receives a credit card number, for example, it can validate that number. Since the server doesn’t need ssl to authenticate your identity, the ssl protocol allows for server authentication only. (The protocol does define a process for authenticating clients. Section 3.7. discusses that process.)
Table 3-8 summarizes the actions each system takes to authenticate a server. The same steps are shown graphically in figure 3-5. The pro- cess isn’t all that different from simple encryption. (Compare figure 3-5 with figure 3-1.) The two messages in black are different when au- thenticating a server. Those messages, the Certificate message and the ClientKeyExchange message, are discussed next. All other mes- sages are the same as described in section 3.3.
Table 3-8 Authenticating a Server Step Action
1 Client sends ClientHello message proposing SSL options. 2 Server responds with ServerHello selecting the SSL options.
Step Action
3 Server sends its public key certificate in Certificate message. 4 Server concludes its part of the negotiation with ServerHello-
Done message.
5 Client sends session key information (encrypted with server’s public key) in ClientKeyExchange message.
6 Client sends ChangeCipherSpec message to activate the nego- tiated options for all future messages it will send.
7 Client sends Finished message to let the server check the newly activated options.
8 Server sends ChangeCipherSpec message to activate the nego- tiated options for all future messages it will send.
9 Server sends Finished message to let the client check the newly activated options. Server ClientHello ServerHello Certificate ServerHelloDone ClientKeyExchange ChangeCipherSpec Finished ChangeCipherSpec Finished 1 2 3 4 5 6 7 8 9 Client
3.5.1 Certificate
When authenticating its identity, the server sends a Certificate mes- sage instead of the ServerKeyExchange message section 3.3.3 de- scribed. The Certificate message simply contains a certificate chain that begins with the server’s public key certificate and ends with the certificate authority’s root certificate.
The client has the responsibility to make sure it can trust the certifi- cate it receives from the server. That responsibility includes verifying the certificate signatures, validity times, and revocation status. It also means ensuring that the certificate authority is one that the client trusts. Typically, clients make this determination by knowing the public key of trusted certificate authorities in advance, through some trusted means. Netscape and Microsoft, for example, preload their browser software with public keys for well-known certificate authori- ties. Web servers that want to rely on this trust mechanism can only obtain their certificates (at least indirectly) from one of these well- known authorities.
One additional detail in the certificate verification process can some- times seem subtle, but is nonetheless crucial for real security: The cli- ent must ensure not only that the certificate is issued by a trusted authority, but that the certificate also unambiguously identifies the party with whom it wants to communicate. Consider, for example, a malicious company that receives a legitimate certificate from a trusted certificate authority under its own name, but then turns around and uses that certificate illegitimately to masquerade as a competitor. The unsuspecting client that communicates with this malicious company (believing that it is communicating with the competitor) will receive a legitimate certificate as part of the ssl ex- change. The client, however, must be intelligent enough to detect that the certificate does not belong to the real competitor. For Web commerce, the key to solving this problem normally relies on the domain name of the server. Respected certificate authorities include the Internet domain name of the Web server in the certificates they issue. And Web browsers check the domain name in certificates they receive against the domain name their users attempt to contact. If,
for example, a browser tries to connect to www.goodcompany.com and receives a certificate for www.badcompany.com, the browser knows something is amiss no matter how valid the certificate other- wise appears. Appendix b contains additional information on verify- ing certificates.
3.5.2 ClientKeyExchange
The client’s ClientKeyExchange message also differs in server au- thentication, though the difference is not major. When encryption only is to be used, the client encrypts the information in the Client- KeyExchange using the public key the server provides in its ServerKeyExchange message. In this case, of course, the server is au- thenticating itself and, thus, has sent a Certificate message instead of a ServerKeyExchange. The client, therefore, encrypts its Client- KeyExchange information using the public key contained in the server’s certificate. This step is important because it allows the client to make sure that the party with whom it is communicating actually possesses the server’s private key. Only a system with the actual pri- vate key will be able to decrypt this message and successfully con- tinue the communication.