Table of Contents
Advertisement
The SSL Handshake
The SSL Handshake
The SSL protocol uses a combination of public-key and symmetric key encryption.
Symmetric key encryption is much faster than public-key encryption, but
public-key encryption provides better authentication techniques. An SSL session
always begins with an exchange of messages called the SSL handshake. The
handshake allows the server to authenticate itself to the client using public-key
techniques, then allows the client and the server to cooperate in the creation of
symmetric keys used for rapid encryption, decryption, and tamper detection
during the session that follows. Optionally, the handshake also allows the client to
authenticate itself to the server.
The exact programmatic details of the messages exchanged during the SSL
handshake are beyond the scope of this document. However, the steps involved
can be summarized as follows (assuming the use of the cipher suites listed in
"Cipher Suites With RSA Key Exchange," which begins on page 268):
The client sends the server the client's SSL version number, cipher settings,
1.
randomly generated data, and other information the server needs to
communicate with the client using SSL.
The server sends the client the server's SSL version number, cipher settings,
2.
randomly generated data, and other information the client needs to
communicate with the server over SSL. The server also sends its own certificate
and, if the client is requesting a server resource that requires client
authentication, requests the client's certificate.
The client uses some of the information sent by the server to authenticate the
3.
server (for details, see "Server Authentication," which begins on page 274). If
the server cannot be authenticated, the user is warned of the problem and
informed that an encrypted and authenticated connection cannot be
established. If the server can be successfully authenticated, the client goes on to
Step 4.
Using all data generated in the handshake so far, the client (with the
4.
cooperation of the server, depending on the cipher being used) creates the
premaster secret for the session, encrypts it with the server's public key
(obtained from the server's certificate, sent in Step 2), and sends the encrypted
premaster secret to the server.
If the server has requested client authentication (an optional step in the
5.
handshake), the client also signs another piece of data that is unique to this
handshake and known by both the client and server. In this case the client
sends both the signed data and the client's own certificate to the server along
with the encrypted premaster secret.
272
Managing Servers with Netscape Console • December 2001
Advertisement
Table of Contents
