The SSL Handshake
Appendix
K
Introduction to SSL
807
The encrypted information exchanged at the beginning of the SSL handshake is
actually encrypted with the rogue program’s public key or private key, rather than
the client’s or server’s real keys. The rogue program ends up establishing one set of
session keys for use with the real server, and a different sent of session keys for use
with the client. This allows the rogue program not only to read all the data that
flows between the client and the real server, but also to change the data without
being deleted. Therefore, it is extremely important for the client to check that the
domain name in the server certificate corresponds to the domain name of the
server with which a client is attempting to communicate—in addition to checking
the validity of the certificate by performing the other steps described in Server
Authentication.
Client Authentication
SSL-enabled servers can be configured to require client authentication, or
cryptographic validation by the server of the client’s identity. When a server
configured this way requests client authentication (see Step 6 of “The SSL
Handshake,” which begins on page 802), the client sends the server both a
certificate and a separate piece of digitally signed data to authenticate itself. The
server uses the digitally signed data to validate the public key in the certificate and
to authenticate the identity the certificate claims to represent.
The SSL protocol requires the client to create a digital signature by creating a
one-way hash from data generated randomly during the handshake and known
only to the client and server. The hash of the data is then encrypted with the
private key that corresponds to the public key in the certificate being presented to
the server.
To authenticate the binding between the public key and the person or other entity
identified by the certificate that contains the public key, an SSL-enabled server
must receive a “yes” answer to the first four questions shown in Figure K-3.
Although the fifth question is not part of the SSL protocol, Netscape servers can be
configured to support this requirement to take advantage of the user’s entry in an
LDAP directory as part of the authentication process.
Содержание Certificate Management System 6.1
Страница 1: ...Administrator s Guide Netscape Certificate Management System Version6 1 February 2003...
Страница 28: ...Documentation 28 Netscape Certificate Management System Administrator s Guide February 2003...
Страница 68: ...Support for Open Standards 68 Netscape Certificate Management System Administrator s Guide February 2003...
Страница 82: ...Uninstalling CMS 82 Netscape Certificate Management System Administrator s Guide February 2003...
Страница 166: ...How a Registration Manager Works 166 Netscape Certificate Management System Administrator s Guide February 2003...
Страница 382: ...ACL Reference 382 Netscape Certificate Management System Administrator s Guide February 2003...
Страница 566: ...Managing Policy Plug in Modules 566 Netscape Certificate Management System Administrator s Guide February 2003...
Страница 710: ...1 3 Organization Security Policies 710 Netscape Certificate Management System Administrator s Guide February 2003...
Страница 716: ...Object Identifiers 716 Netscape Certificate Management System Administrator s Guide February 2003...
Страница 762: ...DNs in Certificate Management System 762 Netscape Certificate Management System Administrator s Guide February 2003...
Страница 794: ...Managing Certificates 794 Managing Servers with Netscape Console December 2001...
Страница 810: ...The SSL Handshake 810 Managing Servers with Netscape Console December 2001...
Страница 828: ...828 Netscape Certificate Management System Administrator s Guide February 2003...