Guidelines on Securing Public Web Servers

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/TLS handshake 

are beyond the scope of this document.  However, the basic steps involved can be summarized 

as follows [SSL98]: 

1.   The client sends the server the client's SSL/TLS version number, cipher settings, 

randomly generated data, and other information the server needs to communicate with 

the client using SSL/TLS.  

2.   The server sends the client the server's SSL/TLS version number, cipher settings, 

randomly generated data, and other information the client needs to communicate with 

the server over SSL/TLS.  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.  

3.   The client uses some of the information sent by the server to authenticate the server.  

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.  

4.   Using all data generated in the handshake to this point, the client (with the 

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.  

5.   If the server has requested client authentication (an optional step in the 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.  

6.   If the server has requested client authentication, the server attempts to authenticate 

the client.  If the client cannot be authenticated, the session is terminated.  If the client 

can be successfully authenticated, the server uses its private key to decrypt the 

premaster secret, then performs a series of steps (which the client also performs, 

starting from the same premaster secret) to generate the master secret.  

7.   Both the client and the server use the master secret to generate the session keys, 

which are symmetric keys used to encrypt and decrypt information exchanged during 

the SSL/TLS session and to verify its integrity   that is, to detect any changes in the 

data between the time it was sent and the time it is received over the SSL/TLS 

connection.  

8.   The client sends a message to the server informing it that future messages from the 

client will be encrypted with the session key.  It then sends a separate (encrypted) 

message indicating that the client portion of the handshake is finished.  

56