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

Alert Protocol in TSL

One of the content types supported by the TLS record layer is the
alert type.Alert messages convey the severity of the message
(warning or fatal) and a description of the alert.Alert messages
with a level of fatal result in the immediate termination of the
connection.In this case, other connections corresponding to the
session may continue, but the session identifier MUST be invalidated,
preventing the failed session from being used to establish new
connections.Like other messages, alert messages are encrypted and
compressed, as specified by the current connection state.

enum { warning(1), fatal(2), (255) } AlertLevel;

enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decryption_failed_RESERVED(21),
record_overflow(22),
decompression_failure(30),
handshake_failure(40),
no_certificate_RESERVED(41),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51),

export_restriction_RESERVED(60),
protocol_version(70),
insufficient_security(71),
internal_error(80),
user_canceled(90),
no_renegotiation(100),
unsupported_extension(110),
(255)
} AlertDescription;

struct {
AlertLevel level;
AlertDescription description;
} Alert;

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.