Transport Layer Security (TLS)

Posted by on 31
August 2012, 8:52 am



Transport
Layer Security (TLS): it relies on Reliable Transport Layer (e.g TCP), transparently supports any application protocols.

One advantage of TLS is that it is application protocol independent. Higher level protocols can layer on top of the TLS Protocol transparently. The TLS standard, however, does not specify how upper layer protocols add security with TLS; the decisions on how
to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left up to the judgment of the designers and implementers of protocols which run on top of TLS.

TLS consists of two components: TLS Record Protocol & TLS Handshake Protocol

TLS
Record Protocol: At the lowest layer of TLS protocol architecture, and it relies on reliable transport protocol (TCP). It provide connection security parameters (symmetric encryption, DES 3DES RC4, MD5 or SHA) per session. TLS Record protocol
is used to encapsulate various higher level protocols such as TLS Handshake protocols.







The Record Protocol takes messages to be transmitted, fragments the data into manageable blocks (2 upper right 14=16384 bytes, upper limit for the length of Record protocol’s Payload Data), optionally compresses the data (encrypted size <= 1024 bytes), applies
a MAC, encrypts, and transmits the result. Received data is decrypted, verified, decompressed, and reassembled, then delivered to higher level clients.

If a TLS implementation receives a record type it does not understand, it should just ignore it.

TLS
Record Protocol Format:











TLS
Handshake protocol: it is responsible for negotiate a series of parameters used for each session as well as the security parameters used by TLS Record Layer, which consists of below items:

session
identifier: one byte sequence uniquely identify each active or resumable session.

peer
certificate:

compress
method: optionally compress the data prior to encryption.

cipher
suite: consists of four security parameters.

Key
exchange algorithm: is used to determine if and how the client and server will authenticate each other during the handshake.

Options for Key Exchange are: RSA, Diffie-Hellman, ECDH, SRP, PSK

Options for Authentication are: RSA, DSA, ECDSA

Bulk
encryption algorithm: It also includes the key size and the lengths of explicit and implicit initialization vectors.

Options are: RC4, DES, 3DES, IDEA, AES.

MAC
algorithm: is used to create the message digest, a cryptographic hash of each block of the message stream.

Options are: MD5 based HAMC or SHA based HMAC

pseudorandom
function (PRF): is used to create the master secret, a 48-byte secret shared between the two peers in the connection. The master secret is used as a source of entropy when creating session keys, such as the one used to create the MAC .

Reference
URL: http://en.wikipedia.org/wiki/Cipher_suite

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.

TLS
Handshake Protocol Format:







TLS
Handshake Phases

Hello Message Exchange

Certification and Key Exchange message

Server Certification is verified by Issuer Authority in the Certification Chain, while the Client Certification is verified by Client sending a digital signature using its private key through Client Certificate Verify message.

Change Cipher Suite and Finished message

TLS
Handshake Procedure:







Client
Hello and Server Hello message: The client hello and server hello 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 (32 bytes = 4 bytes timestamp + 28 bytes random).

struct {

ProtocolVersion client_version;

Random random;

SessionID session_id;

CipherSuite cipher_suites<2..2^16-1>;

CompressionMethod compression_methods<1..2^8-1>;

} ClientHello;

Structure of this message:

struct {

ProtocolVersion server_version;

Random random;

SessionID session_id;

CipherSuite cipher_suite;

CompressionMethod compression_method;

} ServerHello;

session_id

This is the identity of the session corresponding to this connection. If the ClientHello.session_id was non-empty, the server will look in its session cache for a match. If a match is found and the server is willing to establish the new connection using
the specified session state, the server will respond with the same value as was supplied by the client. This indicates a resumed session and dictates that the parties must proceed directly to the finished messages. Otherwise this field will contain
a different value identifying the new session. The server may return an empty session_id to indicate that the session will not be cached and therefore cannot be resumed. If a session is resumed, it must be resumed using the same cipher suite it was originally
negotiated with.

Server
Certificate: The server must send a certificate whenever
the agreed-upon key
exchange method is not an anonymous one. This message will always immediately follow the server
hello message.

Server
Key Exchange message: The server
key exchange message is sent by
the server only when theserver
certificate message (if sent) does not contain enough data to allow the client to
exchange a premaster secret. This message conveys cryptographicinformation
to allow the client to
communicate the premaster secret: either an RSA
public key to encryptthe
premaster secret with, or a Diffie-Hellman public
key with which the client can
complete a key
exchange(with the result being the premaster secret.)

As additional CipherSuites are defined for TLS which
include new key
exchange algorithms, the server
key exchange message will be sent if and only if thecertificate type
associated with the key
exchange algorithm does not provide enough information for theclient to
exchange a premaster secret.

The client and server then use the random numbers (in Client and Server Hello
Message) and PreMasterSecret which is transmitted in an encrypted manner 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.

Certificate
Request: A non-anonymous server can optionally request a certificate from
the client,
if appropriate for the selected cipher
suite. This message, if sent, will immediately follow the Server
Key Exchange message (if it is sent; otherwise, the Server
Certificate message).

Alert
Protocol Format:

this message can be sent at any time during the handshake and up to the closure of the session, to notify a Fatal Error or Warning. If this is used to signal a fatal error, the session will be closed immediately after sending this record, so this record is
used to give a reason for this closure. If the alert level is flagged as a warning, the remote can decide to close the session if it decides that the session is not reliable enough for its needs.







Change
Cipher Specification Protocol & Application Protocol Format: