Handshake Protocol Overview in TSL

The cryptographic parameters of the session state are produced by the
TLS Handshake Protocol, which operates on top of the TLS record
layer.When a TLS client and server first start communicating, they
agree on a protocol version, select cryptographic algorithms,
optionally authenticate each other, and use public-key encryption
techniques to generate shared secrets.

The TLS Handshake Protocol involves the following steps:

-Exchange hello messages to agree on algorithms, exchange random
values, and check for session resumption.

-Exchange the necessary cryptographic parameters to allow the
client and server to agree on a premaster secret.

-Exchange certificates and cryptographic information to allow the
client and server to authenticate themselves.

-Generate a master secret from the premaster secret and exchanged
random values.

-Provide security parameters to the record layer.

-Allow the client and server to verify that their peer has
calculated the same security parameters and that the handshake
occurred without tampering by an attacker.

Note that higher layers should not be overly reliant on whether TLS
always negotiates the strongest possible connection between two
peers.There are a number of ways in which a man-in-the-middle
attacker can attempt to make two entities drop down to the least
secure method they support.The protocol has been designed to
minimize this risk, but there are still attacks available: for
example, an attacker could block access to the port a secure service
runs on, or attempt to get the peers to negotiate an unauthenticated
connection.The fundamental rule is that higher levels must be
cognizant of what their security requirements are and never transmit
information over a channel less secure than what they require.The
TLS protocol is secure in that any cipher suite offers its promised
level of security: if you negotiate 3DES with a 1024-bit RSA key
exchange with a host whose certificate you have verified, you can
expect to be that secure.

These goals are achieved by the handshake protocol, which can be
summarized as follows: The client sends a ClientHello message to
which the server must respond with a ServerHello message, or else a
fatal error will occur and the connection will fail.The ClientHello
and ServerHello are used to establish security enhancement
capabilities between client and server.The ClientHello and
ServerHello establish the following attributes: Protocol Version,
Session ID, Cipher Suite, and Compression Method.Additionally, two
random values are generated and exchanged: ClientHello.random and
ServerHello.random.

 The actual key exchange uses up to four messages: the server
Certificate, the ServerKeyExchange, the client Certificate, and the
ClientKeyExchange.New key exchange methods can be created by
specifying a format for these messages and by defining the use of the
messages to allow the client and server to agree upon a shared
secret.This secret MUST be quite long; currently defined key
exchange methods exchange secrets that range from 46 bytes upwards.

Following the hello messages, the server will send its certificate in
a Certificate message if it is to be authenticated.Additionally, a
ServerKeyExchange message may be sent, if it is required (e.g., if
the server has no certificate, or if its certificate is for signing
only).If the server is authenticated, it may request a certificate
from the client, if that is appropriate to the cipher suite selected.
Next, the server will send the ServerHelloDone message, indicating
that the hello-message phase of the handshake is complete.The
server will then wait for a client response.If the server has sent
a CertificateRequest message, the client MUST send the Certificate
message.The ClientKeyExchange message is now sent, and the content
of that message will depend on the public key algorithm selected
between the ClientHello and the ServerHello.If the client has sent
a certificate with signing ability, a digitally-signed
CertificateVerify message is sent to explicitly verify possession of
the private key in the certificate.

At this point, a ChangeCipherSpec message is sent by the client, and
the client copies the pending Cipher Spec into the current Cipher
Spec.The client then immediately sends the Finished message under
the new algorithms, keys, and secrets.In response, the server will
send its own ChangeCipherSpec message, transfer the pending to the
current Cipher Spec, and send its Finished message under the new
Cipher Spec.At this point, the handshake is complete, and the
client and server may begin to exchange application layer data.(See
flow chart below.)Application data MUST NOT be sent prior to the
completion of the first handshake (before a cipher suite other than
TLS_NULL_WITH_NULL_NULL is established).