The SSL Protocol

In this section, we explain how the Secure Socket Layer (SSL) protocol works using an example in which the client is a Web service requestor and the server is the Web service provider. The steps outlined in Figure A.1 are as follows :

1. The client opens a connection to the server and sends a ClientHello message. This message lists the capabilities of the client, including the version of SSL it is using and the cipher suites it supports.
   
   
2. The server responds with a ServerHello message. The server returns the cipher suite it has chosen and a session ID that identifies this connection.
   
   
3. The server sends its certificate. This is an X.509 site certificate signed by a certificate authority. The certificate contains the server's public key.
   
   
4. The server ( optionally ) sends the client a request for its certificate. Client authentication is necessary for almost all Web services, but if the Web service is a thin veneer directly to a human user , username/password authentication may be used.
   
   
5. The client (optionally, if requested in step 4) sends its certificate. Some trust authority will have signed this certificate, indicating that the server must have policies in place to assign trust levels to. The server may or may not choose to trust that this is really the entity it claims to be.
   
   
6. The client sends a ClientKeyExchange message. The client has created a pre-master shared key and is sending it to the server with this message. The full session key is not created directly because different symmetric ciphers use different key lengths. The browser encrypts this shared key using the server's public key and sends it back to the server.
   
   
7. The client (optionally, if requested in step 4) sends a CertificateVerify message. This is the authentication step in client-authenticated, or "two-way," SSL. The client has to prove it knows the correct private key. The shared key from step 6 is signed using the client's private key (which only it has and which it guarantees it has kept secret) and sent to the server, which verifies this key using the client public key forwarded earlier in the certificate.
   
   
8. Both client and server send a ChangeCipherSpec message, which indicates that both sides are ready to communicate in encrypted form only using the shared secret session key.
   
   
9. Both client and server send a Finished message. This is an MD5 or SHA hash of the entire conversation up to this point to confirm that this entire conversation was received by the other party intact and not tampered with en route.
   
   

Figure A.1. The SSL protocol.