Netscape Certificate Management System 6.1, Administrator'S Manual

Page: 806 / 840

The SSL Handshake
806 Managing Servers with Netscape Console • December 2001
doesn’t correspond to the private key used by the CA to sign the server
certificate, the client won’t authenticate the server’s identity. If the CA’s digital
signature can be validated, the server treats the user’s certificate as a valid
“letter of introduction” from that CA and proceeds. At this point, the client has
determined that the server certificate is valid. It is the client’s responsibility to
take Step 4 before Step 5.
4.
Does the domain name in the server’s certificate match the domain name of
the server itself?
This step confirms that the server is actually located at the
same network address specified by the domain name in the server certificate.
Although step 4 is not technically part of the SSL protocol, it provides the only
protection against a form of security attack known as “man in the middle.”
Clients must perform this step and must refuse to authenticate the server or
establish a connection if the domain names don’t match. If the server’s actual
domain name matches the domain name in the server certificate, the client goes
on to Step 5.
5.
The server is authenticated. The client proceeds with the SSL handshake. If the
client doesn’t get to step 5 for any reason, the server identified by the certificate
cannot be authenticated, and the user will be warned of the problem and
informed that an encrypted and authenticated connection cannot be
established. If the server requires client authentication, the server performs the
steps described in “Client Authentication,” which begins on page 807.
After the steps described here, the server must successfully use its private key to
decrypt the premaster secret the client sends in Step 4 of “The SSL Handshake,”
which begins on page 802. Otherwise, the SSL session will be terminated. This
provides additional assurance that the identity associated with the public key in
the server’s certificate is in fact the server with which the client is connected.
Man-in-the-Middle Attack
As suggested in Step 4 above, the client application must check the server domain
name specified in the server certificate against the actual domain name of the
server with which the client is attempting to communicate. This step is necessary to
protect against a man-in-the-middle attack, which works as follows.
The “man in the middle” is a rogue program that intercepts all communication
between the client and a server with which the client is attempting to communicate
via SSL. The rogue program intercepts the legitimate keys that are passed back and
forth during the SSL handshake, substitutes its own, and makes it appear to the
client that it is the server, and to the server that it is the client.