3.1.1. Procedure – The SSL handshake

As an initial step, both the client and the server collect information to start the encrypted communication.

1. The client sends a CLIENT-HELLO message.

2. The server answers with a SERVER-HELLO message containing the certificate of the server. At this point the parties determine if a new master key is needed.

   Note

   The server stores information (including the session ID and other parameters) about past SSL/TLS sessions in its session cache. Clients that have contacted a particular server previously can request to continue a session (by identifying its session ID); this can be used to accelerate the initialization of the connection. Application-level Gateway currently does not support this feature, but this does not cause any noticeable difference to the clients.

3. The client verifies the server's certificate. If the certificate is invalid the client sends an ERROR message to the server.

   Note
   If a new master key is needed the client gets the server certificate from the SERVER-HELLO message and generates a master key, sending it to the server in a CLIENT-MASTER-KEY message.

4. The server sends a SERVER-VERIFY message, which authenticates the server itself.

5. Optionally, the server can also authenticate the client by requesting the client's certificate with a REQUEST-CERTIFICATE message.

6. The server verifies the certificate received from the client and finishes the handshake with a SERVER-FINISH message.

   Note
   In SSL two separate session keys are used, one for outgoing communication (which is of course incoming at the other end), and another key for incoming communication. These are known as SERVER/CLIENT-READ-KEY and SERVER/CLIENT-WRITE-KEY.