SSL Communication Flow

The different negotiations used by SSL, including cryptographic algorithms, key exchanges, and certificates, are performed concurrently.
Step 1: The client sends a hello record that includes the version of SSL being used (usually TLS 1.0), a list of viable cipher specifications, and a random challenge.
Step 2: The server responds with the selected cipher set and either a server certificate
(server-side certificate) or part of a key exchange. The server may also request a certificate from the client (client-side certificate). The server generates a response to the random challenge that can be validated by the client. This allows the client to identify the server—preventing potential MitM attacks between the client and the server. This does not validate the server; it only prevents a MitM from hijacking the established connection.
Step 3: If the server provides a certificate, then the client contacts a certificate authority (CA) and validates the certificate. Although it is considered secure for the client to validate the certificate, there is nothing in SSL requiring certificate validation. Contacting a CA can add time to the initial connection. If speed is an issue, then the client may choose to not validate the server’s certificate. In addition, some cipher sets, such as SSL3-NULL-MD5 and SSL3-RC4-MD5, do not require a server certificate.
Step 4: The client responds to the server, initiating a key exchange. If a clientside certificate is available, then the client may provide it. (If the server requests a client-side certificate, then one must be provided.) If the server provides a certificate, then the client also provides a message encrypted with the certificate. Similar to Step 2, this allows the server to identify but not validate the client.
Step 5: If the client provides a certificate to the server, then the server may contact a CA to authenticate the client. As with Step 3, the server is not required to validate the client, but servers usually validate client-side certificates.
Step 6: The server sends an encrypted handshake to complete the validation process. At this point, the negotiations and exchanges are complete; the clientand server are both authenticated and validated. An attacker cannot act as a MitM or impersonate the client and server. All further communication uses the agreed upon symmetrical encryption algorithm, which is seeded with the negotiated key exchange values.

Simple TLS handshake

A simple connection example , illustrating a full handshake, follows:

• A client sends a ClientHello message specifying the highest TLS protocol version it supports, a random number, a list of suggested cipher suites and compression methods.
• The server responds with a ServerHello message, containing the chosen protocol version, a random number, cipher suite, and compression method from the choices offered by the client. The server may also send a session id as part of the message to perform a resumed handshake.
• The server sends its Certificate message (depending on the selected cipher suite, this may be omitted by the server).
• The server sends a ServerHelloDone message, indicating it is done with handshake negotiation.
• The client responds with a ClientKeyExchange message, which may contain a PreMasterSecret, public key, or nothing. (Again, this depends on the selected cipher.)
• The client and server then use the random numbers and PreMasterSecret to compute a common secret, called the "master secret". All other key data for this connection is derived from this master secret (and the client- and server-generated random values), which is passed through a carefully designed "pseudorandom function".
• The client now sends a ChangeCipherSpec record, essentially telling the server, "Everything I tell you from now on will be encrypted." The ChangeCipherSpec is itself a record-level protocol, and has type 20, and not 22.
• Finally, the client sends an encrypted Finished message, containing a hash and MAC over the previous handshake messages.
• The server will attempt to decrypt the client's Finished message, and verify the hash and MAC. If the decryption or verification fails, the handshake is considered to have failed and the connection should be torn down.
• Finally, the server sends a ChangeCipherSpec and its encrypted Finished message, and the client performs the same decryption and verification.
• At this point, the "handshake" is complete and the application protocol is enabled, with content type of 23. Application messages exchanged between client and server will be encrypted.