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.

Fragmentation in TSL

The record layer fragments information blocks into TLSPlaintext
records carrying data in chunks of 2^14 bytes or less.Client
message boundaries are not preserved in the record layer (i.e.,
multiple client messages of the same ContentType MAY be coalesced
into a single TLSPlaintext record, or a single message MAY be
fragmented across several records).

struct {
uint8 major;
uint8 minor;
} ProtocolVersion;

enum {
change_cipher_spec(20), alert(21), handshake(22),
application_data(23), (255)
} ContentType;

struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;

type
The higher-level protocol used to process the enclosed fragment.

version
The version of the protocol being employed.This document
describes TLS Version 1.2, which uses the version { 3, 3 }.The
version value 3.3 is historical, deriving from the use of {3, 1}
for TLS 1.0.(See Appendix A.1.)Note that a client that
supports multiple versions of TLS may not know what version will
be employed before it receives the ServerHello.See Appendix E
for discussion about what record layer version number should be
employed for ClientHello.

length
The length (in bytes) of the following TLSPlaintext.fragment.The
length MUST NOT exceed 2^14.

fragment
The application data.This data is transparent and treated as an
independent block to be dealt with by the higher-level protocol
specified by the type field.

Implementations MUST NOT send zero-length fragments of Handshake,
Alert, or ChangeCipherSpec content types.Zero-length fragments of
Application data MAY be sent as they are potentially useful as a
traffic analysis countermeasure.

Note: Data of different TLS record layer content types MAY be
interleaved.Application data is generally of lower precedence for
transmission than other content types.However, records MUST be
delivered to the network in the same order as they are protected by
the record layer.Recipients MUST receive and process interleaved
application layer traffic during handshakes subsequent to the first
one on a connection.

Goals of TLS, RFC 5246

The goals of the TLS protocol, in order of priority, are as follows:

1. Cryptographic security: TLS should be used to establish a secure
connection between two parties.

2. Interoperability: Independent programmers should be able to
develop applications utilizing TLS that can successfully exchange
cryptographic parameters without knowledge of one another's code.

3. Extensibility: TLS seeks to provide a framework into which new
public key and bulk encryption methods can be incorporated as
necessary.This will also accomplish two sub-goals: preventing
the need to create a new protocol (and risking the introduction of
possible new weaknesses) and avoiding the need to implement an
entire new security library.

4. Relative efficiency: Cryptographic operations tend to be highly
CPU intensive, particularly public key operations.For this
reason, the TLS protocol has incorporated an optional session
caching scheme to reduce the number of connections that need to be
established from scratch.Additionally, care has been taken to
reduce network activity.