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: