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).

The TLS Handshaking Protocols

   TLS has three subprotocols that are used to allow peers to agree upon
   security parameters for the record layer, to authenticate themselves,
   to instantiate negotiated security parameters, and to report error
   conditions to each other.

   The Handshake Protocol is responsible for negotiating a session,
   which consists of the following items:
session identifier
      An arbitrary byte sequence chosen by the server to identify an
      active or resumable session state.

   peer certificate
      X509v3 [PKIX] certificate of the peer.  This element of the state
      may be null.

   compression method
      The algorithm used to compress data prior to encryption.

   cipher spec
      Specifies the pseudorandom function (PRF) used to generate keying
      material, the bulk data encryption algorithm (such as null, AES,
      etc.) and the MAC algorithm (such as HMAC-SHA1).  It also defines
      cryptographic attributes such as the mac_length.  (See Appendix
      A.6 for formal definition.)

   master secret
      48-byte secret shared between the client and server.

   is resumable
      A flag indicating whether the session can be used to initiate new
      connections.

   These items are then used to create security parameters for use by
   the record layer when protecting application data.  Many connections
   can be instantiated using the same session through the resumption
   feature of the TLS Handshake Protocol.